AD  AO  47  025 


LABORATORY  FOR 
COMPUTER  SCIENCE 


MASSACHUSETTS 
INSTITUTE  OF j 
TECHNOLOGY 


(formerly  Project  MAC ) 


MIT/LCS/TR-185 


JPEADLOCK  pETECTION [_ 

Inqomputer'networks  - 


D D C 


NOV  23  1977 


Barry /Go)  dm  any 


eitmU 


„ — a This  research  was  supported  by  the 

/gU  Advanced  Research  Projects  Agency  of 

y^^Z-the  Department  of  Defense  and  was  monitored 
— ■ by  the  Office  ol  Naval  Research  under 

Contract  NJN0'0014-75-C-£f661  / 

mzzi 1 


545  T Ft  HNOLOGY  SQUARE,  CAMBRIDGLA1ASS-ACHUSE ITS  02139 


DISTRIBUTION  STATEMENT  A 


Approved  lor  public  release; 
Distribution  Unlimited 


SECURITY  CLASSIFICATION  OP  THIS  PACE  (Whoo  Data  Sngortd) 


J REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMBER  / 2.  OOVT  ACCESSION  NO, 

MIT/LCS/TR-185  * 

S.  RECIPIENT'S  CATALOG  NUMBER 

«.  TltLE  (and  Subtltto)  ' 

Deadlock  Detection  in  Computer  Networks 

s.  type  OF  REPORT  A PERIOD  COVERED 

’S.B.  S.M.Theses.MArch  1977 

«.  PERFORMING  ORO.  REPORT  NUMBER 

MIT/LCS/TR-185 

7.  AuTHbh^i  1 " " 

Barry  Goldman 

CONTRACT  OR  GRANT  NUMBERftJ 

N00014-75-C-0661 

TT  (JUiF&NlilWd  AKcIanization  name  and  address 

MIT/Laboratory  for  Computer  Science  ^ 

545  Technology  Square 

Cambridge.  Ha  02139 

io.  program  Element,  project,  task 

AREA  • WORK  UNIT  NUMBERS 

ti.  controlling  office  name  ano  address 

Advanced  Research  Projects  Agency 

U.  REPORT  DATE 

September  1977 

Mi!nSHS?”v!?glSirfc209 

IS.  NUMBER  OF  PAGES 

181 

11  MOiJIToIIMg  ABIMcY  UAU8  1 XBBHISI//J  dllloront  Irom  Controlling  Ollict) 

Office  of  Naval  Research 

Department  of  the  Navy 

Information  Systems  Program 

Arlington,  Virginia  22217  , 

IS.  SECURITY  CLASS,  (ol  thlo  roport) 

Unclassified 

IS«.  DECLASSIFY  CATION/ DOWN  GRADING 
SCHEDULE 

I IS.  OIsTiuIDtTon  STATEMENT.^/  tMoXoport) 1 

Approved  for  public  release;  distribution  unlimited 

17.  DISTRiIIuTIOH  STATEMENT  (ol  tb»  tbolrtcl  ootondlh  Sloe*  JO,  It  dllltrtnt'irtm  Rtpotl) 


l«.  SUPPLEMENTARY  NOTES 


19.  KEY  WORDS  fCont/nu*  on  rortrt*  old*  II  nocoooory  mtd  Idontlly  by  block  n umbor) 

Deadlock  detection  multiprocessor 

deadlock  resource  allocation 

network 

distributed  computation 
decentralized  computation 


1 20  ABSTRACT  (Contlnuo  on  rovoro*  old*  I t ni>c**o!^S!n3!tuI^‘ hy  bloclt  ■ 1 

The  problem  of  detecting  process  deadlocks  is  common  to  transaction 
oriented  computer  systems  which  allow  data  sharing.  Several  good  algorithms 
exist  for  detecting  process  deadlocks  in  a single  location  facility.  However,* 
the  deadlock  detection  problem  becomes  more  complex  in  a geographically 
distributed  computer  network  due  to  the  fact  that  all  the  information  needed 
to  detect  a deadlock  is  not  necessarily  available  in  a single  node,  and 
communications  may  lead  to  synchronization  problems  in  getting  an  accurate  ^ 

DD"^VT473  EOITION  OF  I NOV  6S  IS  OBSOLETE  —» 


S/N  0102-014-  6601  I 


SECURITY  CLASSIFICATION  OF  THIS  PAOE  fWtan  Dtlo  fntartd) 


tgCUSITV  CLASXFIOTtOW  Of  TWO  PAWHhtm  Pf  BMmMQ 


20>s  view  of  tbr  network  state , 


In  this  thesis,  too  published  algorithms  dealing  with  deadlock 
detection  in  computer  networks  are  discussed,  and  examples  demonstrating  the 
failure  of  these  algorithms  are  given.  Two  algorithms  are  then  presented  for 
detecting  deadlocks  in  a computer  network  which  allows  processes  to  wait  for* 
"tt } access  to  a portion  of  a database,  or  message  from  another  process, 

the  first  algorithm  presented  is  based  on  the  premise  that  there  is  one 
control  node  in  the  network,  and  this  node  has  primary  responsibility  for 
detecting  process  deadlocks.  The  second,  and  recommended,  algorithm  distrib- 
utes the  responsibility  for  detecting  deadlocks  among  the  nodes  in  which  the 
Involved  processes  and  resources  reside.  Thus  a failure  of  any  single  node 
has  limited  effect  upon  the  other  node  in  the  network.  A computer  model  of 
the  ^decentralized "(second)  algorithm  was  designed  and  it  is  described  in 
the  thesis. 


JWOIW  hr 

am  wh  win  V 

Ml  Mf  SmUm  o' 

MMiomiea  □ 

JMTtflMTIM 


nsnwnM/miusiim  ms 
~mh  amil  ut/*  tram 


M1T/LCS/TR-185 


DEADLOCK  DETECTION  IN  COMPUTER  NETWORKS 


Barry  Goldman 


September  1977 


MASSACHUSETTS  INSTITUTE  OF  TECHNOLOGY 

LABORATORY  FOR  COMPUTER  SCIENCE 
(formerly  PROJECT  MAC) 


D D C 

jRrpji  n nrt 

NOV  23  1977 


Cambridge 


MASSACHUSETTS  02139 


Deadlock  Detection  in  Computer  Networks 

by 

Barry  Goldman 


Submitted  to  the  Department  of  Electrical  Engineering  and  Com- 
puter Science  on  March  1,  1977,  in  partial  fulfillment  of  the 
requirements  for  the  Degrees  of  Bachelor  of  Science  and  Master  of 
Science. 


ABSTRACT 


The  problem  of  detecting  process  deadlocks  is  common  to 
transaction  oriented  computer  systems  which  allow  data  sharing. 
Several  good  algorithms  exist  for  detecting  process  deadlocks  in 
a single  location  facility.  However,  the  deadlock  detection 
problem  becomes  more  complex  in  a geographically  distributed 
computer  network  due  to  the  fact  that  all  the  information  needed 
to  detect  a deadlock  is  not  necessarily  available  in  a single 
node,  and  communications  delays  may  lead  to  synchronization 
problems  in  getting  an  accurate  view  of  the  network  state. 

In  this  Thesis,  two  published  algorithms  dealing  with 
deadlock  detection  in  computer  networks  are  discussed,  and  exam- 
ples demonstrating  the  failure  of  these  algorithms  are  given. 

Two  algorithms  are  then  presented  for  detecting  deadlocks  in  a 
computer  network  which  allows  processes  to  wait  for  1)  access  to 
a portion  of  a database,  or  ?)  a message  from  another  process. 
The  first  algorithm  presented  is  based  on  the  premise  that  there 
is  one  control  node  in  the  network,  and  this  node  has  primary 
responsibility  for  detecting  process  deadlocks.  The  second,  and 
recommended,  algorithm  distributes  the  responsibility  for 
detecting  deadlocks  among  the  nodes  in  which  the  involved  pro- 
cesses and  resources  reside.  Thus  a failure  of  any  single  node 
has  limited  effect  upon  the  other  nooes  in  the  network.  A com- 
puter model  of  the  Mdecentral I zed"  (second)  algorithm  was  de- 
signed and  it  is  described  In  the  Thesis. 
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I.  Introduction 


A simple  example  of  deadlock  (or  "deadly  embrace")  occurs 
when  a process  PI  is  blocked  while  waiting  for  access  to  resource 
R2  which  is  controlled  by  process  P2,  and  P2  in  turn  is  blocked 
while  waiting  for  access  to  resource  R1  which  is  controlled  by 
PI.  A deadlock  may  involve  more  than  two  processes.  For  exam- 
ple, process  PI  may  be  waiting  for  access  to  resource  R2  which  is 
controlled  by  process  P2,  P2  may  be  waiting  for  access  to 
resource  R3  which  is  controlled  by  process  P 3 , . ..,  process 
P[n-1]  may  be  waiting  for  access  to  resource  Rn  which  is  con- 
trolled by  process  Pn,  and  Pn  may  be  waiting  for  access  to 
resource  R1  which  is  controlled  by  PI. 

Multiprocessing  and  data  sharing  are  commonly  used  in  a 
single  location  transaction  oriented  computer  system.  In  the 
future  they  will  be  common  to  transaction  oriented,  geographi- 
cally distributed  computer  networks.  In  this  Thesis  an  algorithm 
is  presented  that  can  be  used  to  detect  deadlocks  involving  pro- 
cesses waiting  for  access  to  a shared  portion  of  a database  or 
waiting  for  a message  from  a process  with  which  it  is 
communicating  within  a computer  network.  It  is  possible  that  a 
process  can  be  either  computerized  or  manual,  although  a manual 
process  (i.e.  a person  at  a terminal)  can  not  directly  request 
access  to  a portion  of  a database,  as  it  is  restricted  to  only 
communicate  with  computerized  processes  by  the  use  of  messages. 
Throughout  this  paper,  the  word  "operator"  will  be  used  to  refer 
to  a manual  process. 
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Much  has  been  written  dealing  with  deadlock  detection, 
avoidance  and  prevention  in  computer  systems.  However,  most  of 
the  literature  discusses  a single  location  facility  where  the 
status  of  all  processes  and  resources  are  available  in  a single 
local  table.  (For  a good  discussion,  including  a graph  model  of 
computer  systems  which  can  be  used  to  detect  deadlocks,  see  "Some 
Deadlock  Properties  of  Computer  Systems"  (73.)  Very  few  articles 
have  been  published  that  are  concerned  with  the  deadlock  problem 
in  a computer  network  (geographically  distributed  computer 
system) . 

When  dealing  with  a computer  network  as  opposed  to  a single 
location  facility,  the  deadlock  detection  problem  becomes  more 
difficult  due  to  the  fact  that  all  the  information  needed  to  de- 
tect a deadlock  is  not  necessarily  available  in  a single  node, 
and  communication  delays  may  lead  to  synchronization  problems  in 
getting  an  accurate  view  of  the  network  state.  Some  reasons  for 
restricting  access  to  portions  of  a database  (even  though  the 
result  of  blocking  processes  can  lead  to  deadlock)  and  some  rea- 
sons why  the  common  deadlock  prevention  and  avoidance  algorithms 
are  not  well  suited  to  the  networks  under  consideration  will  be 
discussed.  Several  deadlock  detection  schemes  for  computer  net- 
works (some  from  recent  literature,  some  designed  by  this  author) 
will  be  presented,  and  they  will  be  followed  by  a discussion  of 
some  of  the  benefits  of  using  the  various  schemes. 
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1.1  The  Interference  Problem 

Given  two  or  more  independent  processes,  interference  is 
said  to  have  occurred  if  the  results  produced  by  their  concurrent 
execution  woulu  not  have  been  obtained  by  running  these  processes 
one  at  a time  in  any  order  (i.e.  nonconcurrently) . 

A simple  example  of  Interference  is  the  following.  Let  two 
processes,  PI  and  P2,  read  the  contents  of  database  record  R1. 
Then  let  PI  add  5 to  the  value  and  let  P2  sdd  10  to  the  same 
value.  Now  let  each  process  alter  the  contents  of  R1  to  contain 
the  value  computed  by  that  process.  Depending  upon  the  order  of 
update,  the  contents  of  R1  will  be  either  5 or  10  greater  than 
the  value  that  was  contained  during  the  reads.  We  have  a case  of 
interference  because  the  value  of  R1  would  have  been  15  greater 
than  the  value  contained  at  the  time  of  the  first  read  if  Pi  and 
P2  had  been  executed  sequentially  in  either  order. 

Another  case  of  interference  occurs  when  a process,  in  pro- 
cessing one  transaction,  twice  alters  *he  contents  of  the  same 
database  object  and  in  between  the  two  writes,  a second  process 
reads  the  contents  of  that  database  object.  In  some  cases  a 
process  which  is  only  reading  the  contents  of  a database  object 
may  not  care  if  there  is  any  interference,  in  which  case  it  may 
request  "dirty  read"  access  to  the  database  object.  (A  process 
that  is  only  reading  the  contents  of  a database  object  can  not 
interfere  with  the  values  produced  by  another  process,  although 
other  processes  can  interfere  with  the  values  produced  by  the 
"reading"  process.) 
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When  maximum  concurrency  among  independent  processes  is  de- 
sired, a process  must  be  allowed  to  read  and  alter  the  contents 
of  a database  object  whenever  it  wants  to.  (This  type  of  access 
to  data  has  been  called  "shared  read/shared  write".)  In  order  to 
detect  interference,  records  must  be  kept  about  the  type  of  use 
(read  or  write)  of  each  database  object,  and  what  processes  (and 
when  they)  used  it.  An  algorithm  to  detect  interference  when 
this  information  is  kept  is  presented  in  "On  Managing  Interfer- 
ence Caused  by  Database  Sharing"  [101.  A more  thorough  discus- 
sion of  interference  is  also  given.  After  an  interference 
situation  is  detected,  at  least  one  of  the  Involved  processes 
must  be  forced  to  rollback  to  a previous  state  in  order  to  cor- 
rect the  interference  condition. 

Most  systems,  in  order  to  avoid  Interference  and  guarantee 
that  a process  will  see  a consistent  state  of  a database, 
restrict  access  to  data  by  a system  of  locks.  If  a process  wants 
to  change  the  contents  of  a database  object,  it  must  request  ex- 
clusive access  to  that  database  object,  thus  temporarily  (for  the 
duration  of  the  lock)  preventing  all  other  processes  from 
accessing  that  database  object.  If  a process  only  wants  to  read 
the  contents  of  a database  object,  it  can  request  shared  read 
access  to  that  database  object,  thus  temporarily  (for  the  dura- 
tion of  the  lock)  preventing  all  other  processes  from  altering 
the  contents  of  that  database  object.  If  a database  object  can 
be  shared  among  several  readers,  the  method  of  access  is  called 
"shared  read/exolusive  write",  whereas  if  there  can  be  only  one 


reader,  it  is  called  "exclusive  read/exclusive  write". 


When  a request  for  access  to  a database  object  (resource) 
can  not  be  granted  due  to  the  existence  of  a lock  on  that 
database  object,  the  requesting  process  must  be  blocked  until  the 
resource  becomes  available.  Due  to  processes  waiting  for  access 
to  resources,  there  exists  the  possibility  of  deadlock  among  the 
processes  in  a computer  system. 


1.2  Deadlock  Prevention 

Deadlock  prevention  schemes  place  constraints  upon  system 
users  in  order  to  ensure  that  deadlock  will  never  occur.  There 
is  little  operating  system  c/erhead  involved  when  using 
prevention  methods.  There  are  several  deadlock  prevention  algo- 
rithms ‘‘hat  are  widely  known: 

1.  Each  process  must  request  all  needed  resources  at  one 
time  and  will  remain  blocked  until  all  requests  can  be 
granted  simultaneously.  (This  is  often  referred  to  as 
"static"  allocation.) 

2.  All  resources  are  given  a unique  number  and  processes 
must  request  resources,  one  at  a time,  in  numerical  or- 
der. 

3.  When  an  active  process  requests  a resource  that  is  con- 
trolled by  a blocked  process,  the  blocked  process  must 
release  the  resource  so  that  it  may  be  allocated  to  the 
active  process.  A process  will  go  from  the  active  to 
blocked  state  only  if  it  requests  a resource  controlled 
by  another  active  process. 

The  unpredictability  of  resource  usage  in  a transaction 
oriented  system,  plus  the  loss  of  productivity  that  results  from 
tying  up  resources  unnecessarily  or  forcing  processes  to  release 
resources  and  request  them  later  (which  often  results  in  some 
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redundant  computations  due  to  a process  having  to  repeat  some 
operations  to  maintain  a consistent  database)  make  prevention 
algorithms  undesirable  for  use  in  the  systems  under  considera- 
tion. In  a multiprocessing  environment  which  considers 
inter-process  messages  as  resources,  it  is  impossible  to  have  an 
advance  knowledge  of  all  the  resources  that  will  be  needed  by  a 
process.  Thus  algorithm  1 can  not  be  used  in  this  type  of  sys- 
tem, whether  it  is  a single  or  multi  node  facility.  Algorithm  2 
is  unsuitable  for  the  systems  under  consideration  because  al- 
though it  may  be  possible  to  give  a unique  number  to  each 
inter-process  message,  a process  must  be  "allocated"  each  message 
that  it  will  send  to  another  process,  which  can  result  in  many 
difficulties  when  two  processes  are  sending  severe1  messages  to 
each  other.  Algorithm  3 can  not  be  used  because  it  implies  tnat 
all  resources  must  be  pre-emptable  (i.e.  they  must  be  able  to  be 
released  by  a process  upon  the  demand  of  the  system),  which  is  an 
impossible  situation  when  messages  are  treated  as  resources. 


1.3  Deadlock  Avoidance 

Deadlock  avoidance  algorithms  calculate  safe  paths  for  com- 
pletion of  all  processes.  Before  a resource  is  allocated  to  a 
given  process,  the  operating  system  checks  if  there  would  be  at 
least  one  path  via  which  all  processes  can  run  to  completion 
after  the  allocation  is  made.  If  no  such  path  exists,  then  the 
requesting  process  must  wait  until  a time  when  the  resource  can 
he  safely  allocated  to  the  process.  Avoidance  algorithms  thus 
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force  processes  to  wait  unnecessarily  in  order  to  be  certain  that 
all  processes  will  be  able  to  run  to  completion  without  the 
threat  of  deadlock. 

In  "System  Deadlocks"  [53  it  is  stated  that  "to  avoid 
deadlocks  in  a multiprogramming  system  in  which  the  necessary 
conditions  for  deadlocks  can  exist,  it  is  usually  necessary  to 
have  some  advance  information  on  the  resource  usage  of  tasks," 
When  portions  of  databases  are  considered  resources,  and  they  are 
locked  at  a level  lower  than  a file  (page,  record,  field,  etc.), 
it  is  difficult  to  determine  i » advance  what  database  objects 
will  be  needed.  In  addition,  due  to  the  unpredictability  of 
processes  in  a transaction  oriented  system,  it  is  impossible  to 
have  an  advance  knowledge  of  all  the  inter-process  messages  that 
will  be  requested  by  a process.  Therefore,  deadlock  avoidance 
algorithms  can  not  b'  used  in  a single  or  multi  node  transaction 
system  which  permits  inter-process  communication. 


I.H  Deadlock  Detection 

Since  it  seems  that  deadlock  prevention  and  avoidance  algo- 
rithms are  unsuitable  for  the  distributed  systems  under  consid- 
eration, deadlock  detection  methods  must  be  examined.  When 
employing  a deadlock  detection  algorithm,  requested  resources  are 
usually  assigned  to  the  requesting  processes  whenever  possible, 
and  processes  are  blocked  only  when  desired  resources  are 
unavailable.  Either  the  operating  system  or  a system  user  must 
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must  rollback  (backup)  and  retry  at  least  one  process  in  order  to 
break  the  deadlock.  (It  is  hoped  this  will  force  a new  sequence 
of  access  to  resources.) 
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From  the  implementor’s  viewpoint,  the  easiest  strategy  to 
adopt  is  that  where  one  assumes  deadlock  occurs  infrequently.  In 
this  case  someone  (an  operator)  external  to  the  network  would 
have  the  responsibility  for  detecting  the  deadlock  and  deciding 
what  process  should  be  forced  to  rollback  to  a previous  state. 
With  this  approach  the  only  overhead  involves  the  temporary 
inability  to  access  the  resources  controlled  by  the  deadlocked 
processes  and  the  cost  of  rollback/retry  of  some  (or  all)  of  the 
deadlocked  processes.  (This  cost  may  be  large  for  each  deadlock, 
but  if  there  are  few  deadlocks  the  overall  system  cost  may  be 
less  than  it  would  be  if  there  were  a "deadlock  detector"  that 
was  constantly  checking  for  deadlocks.)  One  could  also  assume 
that  if  a process  has  been  blocked  for  ’X*  units  of  time,  then  it 
is  deadlocked  and  the  operating  system  should  force  it  to 
rollback  to  a previous  state,  although  this  strategy  may  result 
in  some  unnecessary  redundant  computations  because  some  processes 
that  will  be  retried  may  not  have  been  involved  in  a deadlock. 

At  least  two  articles  have  been  published  which  propose 
protocols  for  allocating  database  objects  in  a computer  network 
in  a manner  such  that  deadlock  can  be  detected  at  the  time  a 
request  for  access  is  denied.  In  designing  an  algorithm  to  be 
used  to  detect  process  deadlocks  in  a transaction  oriented  com- 
puter network  which  allows  process  to  process  communication,  it 
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is  necessary  to  allow  for  the  possibility  of  a process  waiting 
for  a message  from  another  process  (which  may  be  manual  or 
computerized).  Additionally,  a process  must  be  allowed  to  wait 
for  access  to  a database  object  which  has  been  allocated  to  at 
least  one  other  process. 

Any  algorithm  that  will  be  implemented  as  part  of  an  oper- 
ating system  should  be  as  efficient  as  possible.  Therefore,  in 
the  algorithms  proposed  by  this  author,  an  attempt  was  made  to 
minimize  the  number  and  size  of  internodal  messages  involved  in 
the  detection  of  deadlocks. 

I.S  Structure  of  the  Thesis 

Chapters  II  and  III  contain  descriptions  and  comments 
(including  some  examples  pointing  out  deficiencies)  relating  to 
two  papers  that  have  been  published  proposing  protocols  for 
allocating  database  objects  in  a computer  network  such  that 
deadlock  can  be  detected  at  the  time  a request  for  access  to  a 
database  object  is  denied.  Chapter  IV  presents  an  introduction 
to  the  two  schemes  for  detecting  deadlock  in  a computer  network 
that  are  proposed  by  this  author  in  Chapters  V and  VI.  The  two 
schemes  differ  in  that  one  (Chapter  V)  places  the  primary  re- 
sponsibility for  detecting  deadlock  anywhere  in  the  network  on 
one  control  node,  whereas  the  other  totally  distributes  the  re- 
sponsibility throughout  the  network.  Chapter  VII  contains  a 
discussion  of  a functional  model  of  the  algorithm  proposed  in 
Chapter  VI.  The  Appendices  contain  a description  and  demonstra 
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tion  of  the  model,  in  addition  to  containing  the  PL/I  code  for 
the  model  itself.  Chapter  VIII  contains  some  suggestions  for 
future  research,  and  Chapter  IX  contains  a comparison  of  the 
various  algorithms  presented  in  Chapters  II,  III,  V and  VI,  plus 
some  concluding  remarks. 

If  one  only  wants  to  read  about  the  algorithm  that  is 
recommended  by  this  author,  it  is  possible  to  read  Chapters  IV 
and  VI  with  no  loss  of  understanding.  Chapter  VII  can  also  be 
understood  after  reading  Chapters  IV  and  VI;  as  can  the  Appendi- 
ces and  some  portions  of  Chapter  VIII. 
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* II.  Proposal  of  Chandra,  Howe  and  Karp 

In  "Communication  Protocol  for  Deadlock  Detection  in  Com- 
puter Networks"  C 33 * a scheme  Is  presented  which  the  authors  call 
wa  novel  solution  to  the  deadlock  problem  in  the  network 
environment."  Their  "solution"  is  described  below,  and  the  de- 
scription is  followed  by  an  example  where  the  scheme  allows  a 
deadlock  to  go  undetected. 

II. 1 Chandra,  Howe  and  Karp's  Proposed  Solution 

The  authors  propose  that  each  installation  (node)  maintain  a 
resource  table  (RT)  which  contains  information  about  which  pro- 
cesses have  been  allocated  local  resources,  which  processes  have 
been  queued  (waiting  for  access)  for  local  resources,  which  local 
processes  have  been  allocated  remote  resources  and  which  local 
processes  have  been  queued  for  remote  resources.  The  type  of 
access  requested  by  each  process  is  also  recorded.  The  authors 
claim  that  in  a single  node  facility,  there  are  several  well 
known  algorithms  for  detecting  deadlocks  using  the  tables 
mentioned  above.  They  then  state  "it  is  believed  to  be  obvious 
that  these  same  algorithms  would  suffice  in  the  multiple  instal- 
lation case  provided  that  the  resource  table  were  to  be  expanded 
to  include  the  pertinent  information  from  the  remote  sites."  A 
scheme  to  expand  the  resource  table  in  a node  is  given  in  the 
paper. 

The  authors  believe  there  are  three  types  of  requests  for 
resources  that  can  lead  to  deadlock.  (In  all  cases,  "it  is  as- 
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sumed  that  the  requested  resource  is  not  available,  because,  if 
it  were,  the  allocation  would  take  place  immediately.”)  The  ac 
tion  taken  for  each  type  of  request  is  the  following  (as  stated 
in  the  paper): 

Case  1 


A process  requests  a local  resource,  which  is  allocated 
to  a local  process,  and  all  of  the  processes  which  are 
queued  for  this  resource  are  also  local  processes.  All  of 
the  necessary  information  is  contained  in  the  local  RT,  and 
the  request  is  resolved  locally. 

Case  2 


A process  requests  a local  resource,  which  is  either 
allocated  to  a remote  process  or  one  or  more  of  the  pro- 
cesses that  are  queued  for  this  resource  are  remote 
processes.  In  this  case,  all  of  the  RT's  must  be  obtained 
by  the  local  installation  since  deadlock  may  occur.  Once 
all  of  the  RT's  have  been  obtained,  the 
deadlock-determination  algorithm  can  be  applied  to  the 
expanded  RT  which  conta-ns  all  of  the  resources  and  pro- 
cesses in  the  total  community  of  Installations. 

Case  3 


A process  requests  a resource  at  some  remote  installa- 
tion. In  this  case,  the  requesting  installation  forwards 
the  request  and  its  RT  to  the  installation  which  has  the 
requested  resource.  This  installation  then  determines  if 
the  request  can  be  honored  immediately  or  if  all  of  the  RT’s 
must  be  first  obtained.  In  the  case  where  the  requested 
resource  is  allocated  to  or  queued  by  only  processes  local 
to  the  two  involved  systems,  the  request  can  be  honored  im- 
mediately. Otherwise,  this  installation  obtains  the  RT's 
from  the  remaining  installations  and  then  resolves  the 
request . 

In  all  of  these  cases,  the  RT's  that  are  involved  in 
the  decision  procedure  must  be  locked  until  after  the  deci- 
sion has  been  made.  If  the  decision  involves  the  RT's  of 
the  other  installations  in  the  community,  these  installa- 
tions must  be  notified  after  the  decision  is  made  and  their 
table  is  then  released.  In  Case  3,  the  updates  to  the  RT 
must  be  returned  to  the  requesting  installation  while  all 
other  tables  can  he  discarded  and  a simple  release  notice 
returned . 
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or  more  installations  may  simultaneously  request  the  various  RT's 
in  order  to  make  an  allocation  for  two  or  more  independent 
requests.” 
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II. 2 A Fault  in  the  Proposed  Solution 

There  are  some  resource  requests  which  fall  under  Case  1, 
and  result  in  a deadlock  for  which  the  locsl  RT  does  not  contain 
enough  information  to  detect.  Consider  the  following  example: 

Let  the  network  consist  of  two  nodes,  A and  B.  Let 
processes  PI  and  P2  and  resource  R1  be  local  to  A,  and  let 
processes  P3  and  PH  and  resources  R2,  R3,  and  RH  be  local  to 
B.  Assume  the  following  state  of  the  network.  (Figure 
II,  la  contains  a diagram  of  this  ‘’intermediate"  state.)  PI 
has  exclusive  control  of  R1  and  is  queued  waiting  for  access 
to  RH,  P2  has  exclusive  control  of  R2  and  is  queued  waiting 
for  access  to  R1,  P3  has  exclusive  control  of  R3  and  is 
queued  waiting  for  access  to  R2,  and  PH  is  active 
(non-blocked)  and  has  exclusive  control  of  RH.  In  this 
state  there  is  no  deadlock.  Now  let  PH  request  access  to  R3 
and  be  queued  for  the  resource.  A deadlock  now  exists  (see 
Figure  II. 1b)  involving  all  four  processes  and  all  four 
resources.  With  the  tables  as  described  in  the  article, 
this  deadlock  could  not  be  detected  unless  node  A sent  node 
P its  tables,  but  this  does  not  take  place  because  the 
request  falls  into  Case  1 (since  PH  is  local  to  B,  as  are  P3 
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and  R3).  Therefore  the  deadlock  goes  undetected. 


Similar  examples  (for  networks  consisting  of  three  or  more 
..•odes)  exist  where  requests  falling  under  Case  3 result  in 
undetected  deadlocks.  RT’s  from  3 or  more  nodes  may  be  needed 
even  if  "the  requested  resource  is  allocated  to  or  queued  by  only 
processes  local  to  the  two  involved"  nodes. 
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Intermediate  State  Diagram 
Figure  II . la 
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Final  State  Diagram 
Figure  II. 1b 


Represents  a process 
Represents  a resource 


Li  ^®P**esen^s  a process  having  exclusive  use  of  a resource 

Q— *□  ^®Pre*®rjts  a process  waiting  for  access  to  a resource 


III.  Proposals  of  Mahmoud  and  Riordon 

In  "Protocol  Considerations  for  Software  Controlled  Access 
Methods  in  Distributed  Data  Bases"  C 8 1 , two  schemes  are  presented 
for  allocating  database  files  in  a network  environment.  The 
authors  (Professors  at  Carleton  University,  Ottawa,  Ontario, 
Canada)  claim  that  with  their  schemes,  by  using  the  graphic  rep- 
resentation as  described  in  [9],  deadlocks  can  be  detected  at  the 
time  an  allocation  decision  is  made.  The  two  schemes  are  de- 
scribed below,  and  a brief  discussion  about  the  schemes  follows, 
including  an  example  where  one  of  the  proposals  allows  a deadlock 
to  go  undetected. 

The  first  approach  described  requires  that  all  deadlock 
tests  be  made  by  one  node,  whereas  with  the  second  approach  each 
node  must  teat  for  deadlock  resulting  from  different  processes 
accessing  its  files.  Each  node  in  the  network  will  contain  a 
Distributed  Data  Base  Management  Facility  (DDBMF)  which  will 
communicate  with  the  other  DDBMF  processes  In  the  network  for  the 
purpose  of  handling  requests  for  local  and  remote  processes. 

III.1  Mahmoud  and  Riordon’s  Centralized  Control  Approach 

In  the  centralized  approach,  one  node,  called  the  control 
node,  will  make  all  the  deadlock  tests  and  handle  all  file 
allocations.  If  a process  running  at  node  i would  like  access  to 
a file  in  node  j,  a request  is  sent  to  the  DDBMF  in  node  i,  which 
then  relays  it  to  the  central  DDBMF,  even  if  node  i and  node  j 
are  the  same.  Since  the  central  DDBMF  makes  all  the  file 
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allocation  decisions,  it  has  an  overall  picture  of  the  global 
network  status,  and  can  therefore  decide  if  the  request  can 
safely  (without  deadlook)  be  placed  on  the  file  queue. 


Til. 2 Mahmoud  and  Riordon’s  Distributed  Control  Approach 

In  the  distributed  approach,  the  DDBMF  at  each  node  will 
have  full  control  over  all  access  to  the  files  located  at  its 
node.  As  a result  of  this,  the  authors  state  that  "each  node 
DDBMF  will  be  responsible  for  handling  job  interference 
(deadlock)  problems  that  may  arise  while  different  processes  are 
accessing  its  files."  In  order  to  avoid  or  detect  deadlocks 
involving  processes  and  files  located  at  two  or  more  nodes,  "each 
Individual  DDBMF  must  obtain  information  from  other  DDBMF  pro- 
cesses indicating  the  status  of  their  files  and  queue  tables. 

The  information  will  be  used  ...  to  construct  a global  picture  of 
the  network  and  thus  enable  each  individual  DDBMF  process  to  make 
the  correct  decisions." 

All  active  user  processes  are  separated  into  two  classes. 

In  the  authors’  own  words, 

The  classification  is  based  on  the  localities  of  the  files 
requested  by  the  process  and  the  type  of  access  to  each  of 
these  files: 

Class  1:  each  process  belonging  to  this  class  has  the  fol- 
lowing properties: 

1)  All  files  accessed  by  the  process  during  its  active 
session  are  located  in  a single  node. 

2)  All  files  being  updated  by  the  process  are  single-copy 
files  in  the  network  (i.e.  only  a single  copy  of  each 
file  exists  in  the  network). 

Class  2:  each  user  process  belonging  to  this  class  has  the 
following  properties: 

1)  Files  that  are  accessed  simultaneously  by  the  process 
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during  an  active  session  do  not  all  exist  in  a single 
computer  system  and/or 

2)  Any  one  of  the  files  being  updated  by  the  process  has 
multiple  copies  in  the  network. 

It  is  obvious  that  the  two  classes  of  processes  are 
mutually  exclusive. 

The  authors  suggest  using  a graph  representation  in  order  to 
detect  deadlock,  and  they  describe  how  a DDBMF  gets  information 
from  the  other  DDBMF's  in  the  network  and  when  it  should  check 
for  deadlock: 

Assume  that  there  are  n nodes  in  the  network,  i.e.,  n 
individual  DDBMF  processes.  Each  process  will  transmit 
(n-1)  identical  messages  simultaneously,  with  one  message 
addressed  to  each  of  the  remaining  DDBMF  processes.  Each 
message  contains  the  most  updated  information  about  the 
status  and  queues  of  files  at  the  node  in  question.  The 
messages  will  be  transmitted  periodically  at  the  onset  of 
synchronous  clock  intervals.  Similarly,  each  DDBMF  process 
will  receive  periodically  (n-1)  messages  from  the  other 
processes.  Now  assume  that  a DDBMF  process  receives  a 
request  for  access  to  one  of  the  files  under  its  control 
from  a local  or  remote  user  process.  If  the  requesting 
process  belongs  to  class  1,  the  DDBMF  will  respond  immedi- 
ately to  the  request.  Otherwise  the  DDBMF  will  delay  action 
until  the  next  time  interval,  i.e.,  until  receiving  updated 
information  about  the  status  of  the  network  files  from  other 
DDBMF  processes.  The  request  is  then  checked  against  any 
possible  interference  (deadlock)  and  the  user  process  is 
notified  once  a decision  is  made. 

Requests  which  car  not  be  acted  upon  until  the  next  time 

interval  are  placed  in  a pre-test  queue. 

At  the  beginning  of  a clock  interval,  each  processor 
receives  information  from  other  processors  including  the 
contents  of  the  file  queues  and  the  pre-test  queue.  The 
processor  extracts  the  contents  of  the  pre-test  queues  and 
corbines  them  to  construct  a global  pre-test  queue  which 
includes  all  the  requests  for  file  access  received  by  all 
processors  during  the  previous  time  interval.  The  file  ac- 
cess requests  on  the  global  pre-test  queue  are  tested  for 
deadlock  conditions  and  decisions  are  then  made. 

To  avoid  deadlock  situations  caused  by  critical  race 
conditions,  the  file  access  requests  on  the  global  pre-test 


queue  must  be  arranged  in  the  same  order  in  all 
processors...  All  processors  must  then  follow  a predefined 
routine  in  constructing  the  global  pre-test  queue.  The 
resulting  versions  of  the  global  pre-test  queue  will  be 
identical  in  all  processors  at  the  beginning  of  every  clock 
interval . 


III. 3 Some  Comments  about  the  Proposed  Schemes 

The  authors  state  that  their  schemes  will  work  if  records, 
or  other  units  serve  as  the  identifiable  unit  of  object  data, 
rather  than  files,  which  were  mentioned  throughout  the  paper. 

When  records  are  allocated  individually,  there  will  be  more  mes- 
sage traffic  due  to  additional  message  requests  for  access  to 
database  objects.  Nowhere  in  the  paper  is  the  problem  of  message 
congestion  at  the  control  node  (when  using  the  Centralized 
approach)  discussed.  With  all  requests  for  access  to  database 
objects  being  handled  by  the  central  DDBMF,  there  exists  the 
possibility  of  a message  bottleneck  at  the  control  node,  which 
would  degrade  network  performance  due  to  slow  response  to  the 
requests. 

It  is  mentioned  that  failure  of  the  control  node  (when  using 
the  Centralized  approach)  can  "paralyze  the  operation  of  the 
whole  system,"  although  all  the  DDBMF's  can  send  all  their  in- 
formation to  another  DDBMF,  thus  recreating  the  global  picture  of 
the  system  at  a newly  designated  control  node.  Although  the 
author’s  Centralized  approach  may  ue  "inefficient,"  it  can  be 
used  to  successfully  detect  all  process  deadlocks  when  only  wait 3 
on  database  objects  are  involved, 

The  Decentral ized  approach,  ss  described  in  the  paper,  does 
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not  detect  all  deadlock  situations  when  only  process  waits  for 
database  objects  are  involved.  Consider  the  following  example: 


Let  the  network  consist  of  two  nodes,  A and  B.  Let 
processes  PI  and  P?,  and  files  FI  and  F2  be  local  to  node  A, 
and  let  processes  P3  and  P4,  and  files  F3  and  FA  be  local  to 
node  B.  Assume  the  following  state  of  the  network.  (Figure 
III. la  contains  a diagram  for  this  "intermediate"  state.) 

PI  has  exclusive  control  of  FI  and  is  queued  waiting  for 
access  to  FA,  P2  is  active  (non-blocked)  and  has  exclusive 
control  of  F2,  P3  has  exclusive  control  of  F3  ana  is  queued 
waiting  for  access  to  F2,  and  PA  is  active  and  has  exclusive 
control  of  FA.  PI  and  P3  belong  to  class  2,  as  defined  by 
Mahmoud  and  Rlordon,  and  P 2 and  PA  both  belong  to  class  1 as 
long  as  each  does  not  request  access  to  a file  located  in  a 
node  other  than  the  one  in  which  the  process  resides. 

Now,  within  the  same  time  interval,  let  P2  request  ac- 
cess to  FI  and  let  PA  request  access  to  F3,  thus  creating  a 
deadlock  because  neither  file  can  become  available.  (Figure 
III. 1b  contains  the  final  state  diagram  for  this  deadlock.) 
P2  and  PA  remain  class  1 processes,  and  therefore  these 
requests  should  be  acted  upon  immediately  and  each  node  will 
check  for  deadlock  using  the  information  that  it  has.  No 
deadlock  will  be  detected  because  neither  node  has  the  in- 
formation about  the  recent  request  in  the  other  node,  and  no 
provisions  are  stated  in  the  article  which  imply  that 
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deadlock  involving  P 2 or  P*t  will  be  checked  for  at  the  onset 
of  the  next  synchronous  clock  period. 

The  authors  believe  that  class  1 processes  do  not  contribute 
to  deadlocks  that  involve  processes  waiting  for  files  located  in 
wore  than  one  node,  and  therefore  deadlock  can  be  checked  for 
using  only  the  information  located  at  one  node  when  a class  1 
process  requests  access  to  a file.  It  is  this  assumption  that 
leads  to  the  downfall  of  their  Decentralized  approach,  because  it 
is  possible  that  a class  1 process  will  request  access  to  a file 
controlled  by  a class  2 process,  resulting  in  a deadlock  (as 
shown  in  the  previous  example)  involving  processes  which  are 
collectively  waiting  for  access  to  files  located  in  two  or  more 
nodes.  Note  that  this  is  similar  to  the  flaw  in  the  protocols 
for  deadlock  detection  proposed  by  Chandra,  Howe  and  Karp. 
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Intermediate  State  Diagram 
Figure  III. la 


Final  State  Diagram 


Figure  III. 1b 

KFY 

(^)  Represents  a process 

} ] Represents  a file 

| ]—>Q  Represents  a process  having  exclusive  use  of  a file 

ry-j  I Represents  a process  waiting  for  access  to  a file 


IV.  Introduction  to  Proposed  Solutions 
The  deadlock  detection  schemes  that  are  presented  in 
Chapters  V and  VI  are  based  on  the  creation  and  expansion  of  or- 
dered blocked  process  lists  (OBPL’s)  and  the  restriction  that  a 
process  may  only  have  one  unapproved  outstanding  resource  request 
(and  therefore  be  waiting  for  at  most  one  resource  at  any 
instant).  A resource  may  be  any  non-ambiguously  defined  portion 
of  an  object,  whole  object,  or  collection  of  objects  which  are 
requested  as  an  entity  and  released  as  an  entity  by  all  users. 
(The  case  where  there  are  several  equivalent  resources  like  tape 
drives  is  not  considered.  A discussion  of  physical  devices  oc- 
curs later  in  this  chapter.)  An  OBPL  is  a list  of  process  names, 
each  of  which  (with  the  exception  of  the  last  process  in  the 
list)  is  waiting  for  access  to  a resource  that  has  been  assigned 
to  the  next  process  in  the  list.  Each  process  name  in  the  list 
is  often  referred  to  as  a process  entry  in  the  OBPL,  and  when  an 
OBPL  is  sent  between  nodes,  a resource  name  is  inserted  into  the 
single  resource  identification  portion  of  the  OBPL.  The  last 
process  to  have  an  entry  in  the  OBPL  is  either  waiting  for  access 
to  the  resource  named  in  the  resource  identification  portion,  or 
it  already  has  access  to  that  resource.  In  the  former  case,  it 
must  be  determined  what  process  controls  the  resource,  whereas  in 
the  latter  case,  the  state  of  the  last  process  in  the  OBPL  must 
be  determined. 

It  is  assumed  that  at  each  node  there  is  a process  manage- 
ment module  "’’MM)  which  will  handle  deadlock  detection  and 


resource  allocation.  It  will  maintain  local  state  tables  which 
will  contain  information  about  local  resources  (resources  which 
are  located  in  that  node)  and  local  processes  (processes  which 
are  running  in  that  node).  If  a PMM  is  cheeking  for  deadlock, 
and  it  is  examining  the  OBPL  with  process  entries  PI,  P2,  ..., 

PN,  then  it  knows  that  each  process  in  the  list  (with  the 
exception  of  PN)  is  waiting  for  the  next  process  in  the  list  to 
release  a desired  resource.  If  PN  is  not  blocked,  there  is  no 
deadlock  ar,d  the  OBPL  can  be  discarded.  If  it  is  blocked,  then  a 
PMM  must  find  out  what  process  has  been  allocated  the  resource 
for  which  PN  is  waiting.  If  this  process  already  has  an  entry  in 
the  OBPL,  there  is  a deadlock,  otherwise  a PMM  must  append  the 
process  name  to  the  OBPL  and  repeat  the  above.  The  schemes  that 
are  being  proposed  differ  from  each  other  in  the  way  the  OBPL’s 
get  expanded. 

IV. 1 Descriptions  of  Resources 

There  are  three  types  of  resources  that  a process  may  wait 
for  where  the  blocking  of  the  process  can  result  in  a deadlock. 
They  are  database  objects,  message  text  from  other  computerized 
processes,  and  message  text  from  operators  (manual  processes).  A 
distinction  is  made  between  message  text  from  processes  and  mes- 
sage text  from  operators  because  a deadlock  which  involves  no 
operator  messages  can  be  detected  without  operator  interaction, 
whereas  if  a process  is  waiting  for  message  text  from  an  opera- 
tor, a deadlock  can  not  be  detected  without  the  operator  stating 
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what  he/she  is  waiting  for.  The  reason  for  the  latter  point  is 
that  an  operator  typically  does  not  type  in  "receive  message" 
statements,  but  accepts  output  as  it  is  given.  In  the  algorithms 
presented,  it  is  assumed  that  an  operator  can  only  wait  for  a 
message  from  a process  with  which  he/she  is  communicating  (a 
discussion  of  operator  and  process  communication  is  given  later 
in  this  section).  This  restriction  can  be  relaxed,  and  it  is 
discussed  in  Chapter  VIII. 

Database  objects,  as  discussed  in  this  paper,  can  be  fields, 
records,  files,  or  any  other  logical  or  physical  component  of  a 
database.  It  is  Important  that  all  processes  treat  the  same 
portion  of  a database  identically  for  the  purposes  of  allocation. 
The  level  of  granularity  (which  may  vary  for  different  database 
objects)  at  which  database  objects  are  allocated  is  unimportant 
for  the  detection  of  deadlock;  it  does  however,  affect  the 
frequency  of  deadlock  and,  conversely,  the  burden  of  maintaining 
information  about  resource  allocation. 

Message  text  must  be  treated  differently  from  database  ob- 
jects because  once  a message  text  has  been  assigned  to  a process, 
it  is  not  available  to  any  other  process.  In  this  sense,  once  a 
message  text  has  been  assigned,  it  no  longer  exists  for  future 
assignment.  To  ensure  that  a process  receives  the  proper  message 
text,  the  sending  and  receiving  processes  must  create  a unique 
connection  over  which  message  text  between  the  two  processes  may 
oass.  When  a process  would  like  to  receive  message  text,  it  must 
state  over  which  previously  established  connection  the  text 
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should  cone.  Similarly,  when  a process  wants  to  send  message  j 

a 

4 

text,  it  must  give  the  message  text  and  name  the  connection  over  j 

3 

which  the  text  should  pass.  All  messages  that  are  sent  and  1 

received  over  a given  connection  will  be  referred  to  as  text 

- J! 

within  a specific  message  group.  : 

4 

When  message  text  is  sent  by  a process,  it  is  queued  for  •] 

receipt  at  the  proper  destination  end  of  the  connection.  A pro- 
cess may  send  several  items  of  message  text  over  a given  connec- 
tion before  any  messages  are  requested  by  the  other  process  as- 
sociated with  the  connection.  In  this  ease  the  items  of  message 
text  are  queued  for  receipt  in  a first  in,  first  out  manner.  It 
is  assumed  that  message  management  has  infinite  queueing 
capacity,  and  therefore  the  possibility  of  a deadlock  involving  a 
process  which  wants  to  send  a message  but  is  blocked  because 
there  is  no  place  to  put  the  message  text  will  not  be  dealt  with. 

Unlike  process  to  process  messages,  which  may  be  sent  be- 
tween nodes,  when  a process  and  an  operator  communicate,  they 
must  be  located  at  the  same  node.  Similarly,  however,  an 
"operator  connection"  must  be  established  between  the  operator 
and  process  before  message  text  can  be  sent  over  the  connection. 

The  operator  connection  must  be  specified  when  message  text  is 
sent  or  received  over  the  connection.  When  messages  are  sent 
from  a process  to  an  operator,  they  are  usually  printed  immedi- 
ately at  the  operator’s  terminal.  However,  messages  that  are 
sent  from  an  operator  to  a process  are  queued  for  receipt  in  the 
same  manner  as  process  to  process  messages. 


30 


I 

i 


All  of  the  resources  described  above  are  uniquely  Identifi- 
able, and  are  allocated  dynamically  (i.e.  during  the  execution  of 
the  process  requesting  access  to  the  resource).  None  of  tht»m  are 
physical  devices  (tape  drives,  printers,  etc.),  which  are  often 
not  uniquely  identifiable  (there  may  be  N of  a kind).  Physical 


devices  are  not  considered  by  the  algorithms  that  are  being  pro- 
posed because  they  are  typically  allocated  to  a process  before 
execution  begins  and  the  known  networks  restrict  processes  to 
requesting  physical  devices  at  the  same  node.  (If  a process 
wants  to  control  a physical  device  at  another  node,  it  must  do  so 
indirectly  through  a process  located  at  the  same  node  as  the  de- 
sired device.)  Additionally,  transaction  oriented  processes 
typically  do  not  use  dedicated  devices. 
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IV. 2 Access  to  Resources  and  the  Blocking  of  Processes 
A process  may  get  blocked  when  it  requests  read  only 
(shared)  access  or  exclusive  (read/write)  access  to  a database 
object.  While  one  process  has  exclusive  access  to  a specific 
database  object,  all  r quests  for  access  to  that  database  object 
result  in  the  requesting  process  being  blocked.  While  at  least 
one  process  has  shared  access  to  a specific  database  object,  all 
requests  for  exclusive  access  to  that  database  object  result  in 
the  requesting  process  being  blocked,  and  requests  for  shared 
access  to  that  database  object  will  result  in  the  requesting 
process  being  blocked  or  being  granted  access  to  the  desired 
resource  (depending  upon  the  resource  allocation  scheme  in  use). 
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Because  data  values  are  not  changed  when  a process  only  reads  a 
database  object,  any  number  of  processes  may  be  allowed  to  have 
concurrent  read  only  access  to  a database  object.  When  all  pro- 
cesses that  had  shared  access  to  a given  database  object  have 
released  it,  or  when  a process  releases  a database  object  from 
exclusive  use,  at  least  one  process  will  be  awakened  and  granted 
access  to  the  newly  released  database  object,  if  any  were  waiting 
for  access  to  it. 

Once  a process  has  been  granted  shared  access  to  a specific 
database  object,  subsequent  requests  by  that  process  for  exclu- 
sive access  to  that  database  object  are  rejected.  This  restric- 
tion prevents  a process  from  getting  blocked  waiting  for  a 
database  object  that  it  already  has  access  to,  and  implies  that  a 
process  must  declare  its  most  restrictive  use  when  it  requests 
access  to  the  database  object.  (It  must  request  exclusive  access 
if  there  is  any  chance  that  the  process  might  change  the  content 
of  the  database  object.)  In  order  to  ensure  that  a process  has  a 
consistent  view  of  the  database,  and  that  processes  may  be  rolled 
back  to  a previous  state  (when  necessary),  no  database  objects 
will  be  released  by  a process  until  that  process  has  reached  a 
"commitment  point",  at  which  time  all  the  database  objects  that 
the  process  had  access  to  are  released.  A commitment  point  is 
always  reached  at  process  termination.  (When  a process  continues 
processing  after  reaching  a commitment  point,  for  purposes  of 
detecting  deadlock,  a PMM  can  treat  it  as  a new  process  because 
it  released  all  its  database  resources,  and  notified  all  pro- 

i? 


1 


3i 


cesses  to  which  it  could  send  messages  that  no  mere  messages  are 
forthcoming.  The  external  effects  of  a process,  including 
database  updates  and  message  text  sent,  can  not  be  cancelled 
after  commitment.  Process  commitment  points  are  synchronized, 
which  is  to  say  that  after  a process  reaches  a commitment  point, 
it  does  no  further  processing  until  all  processes  with  which  it 
has  established  connections  over  which  it  can  receive  messages 
have  also  reached  commitment  points.) 

If  a process  attempts  to  receive  message  text  over  a speci- 
fic connection,  it  will  be  given  one  message  if  any  are  queued 
for  receipt  at  that  process’es  end  of  the  connection.  If  no 
messages  are  available,  the  process  is  blocked  until  message  text 
arrives.  Upon  arrival  of  a message,  the  process  will  be 
awakened,  because  the  receiving  process  is  uniquely  identified  by 
the  connection  over  which  message  text  is  sent.  Steps  must  be 
taken  to  ensure  that  the  receiving  process  and  the  sending  pro- 
cess of  a message  treat  the  same  text  as  one  message.  (One  pro- 
cess can't  treat  a line  as  a message  when  the  other  process 
treats  a group  of  sentences  as  a message.) 

IV. 3 Creation  and  Expansion  of  an  OBPL 

When  a PMM  wants  to  check  whether  a given  blocked  process  is 
involved  in  a deadlock,  it  creates  an  OBPL  and  inserts  the  net- 
work unique  name  of  the  process  as  the  first  process  entry  in  the 
OBPL.  (It  is  assumed  that  operators,  processes  and  resources 
have  unique  names  within  a node,  and  these  names  can  be  made 
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unique  within  a network  by  qualifying  them  with  the  name  of  the 
node  in  which  they  reside.  Throughout  this  Thesis,  operator, 
process  and  resource  names  are  assumed  to  be  network  unique.) 

Call  this  process  PI.  Let  R1  be  the  resource  to  which  PI  desires 
access.  R1  is  then  inserted  into  the  resource  identification 
portion  of  the  08PL.  A PMM  (which  PMM  depends  upon  what  scheme 
is  being  used  to  detect  deadlock,  and  whether  PI  and  R1  are  in 
the  same  node)  then  determines  what  process  controls  R1.  If  R1 
is  a database  object,  then  the  process  that  controls  R1  is  the 
process  that  has  access  to  it,  (If  there  are  several  shared 
readers  of  R1,  then  it  is  said  that  each  reader  controls  R1  and 
the  OPPL  is  copied  enough  times  so  that  there  is  one  list  for 
each  reader  of  R 1 , and  a different  copy  of  the  OBPL  is  used  for 
each  reader.)  If  R1  is  message  text  in  a message  group,  then  the 
process  that  controls  R1  is  the  process  that  can  send  the  desired 
message,  and  if  R1  is  message  text  from  an  operator  connection, 
the  process  that  controls  the  resource  is  the  human  operator  that 
can  send  the  message.  If  R1  is  message  text  over  a connection  to 
which  no  process  other  than  PI  has  associated  itself,  the  PMM 
saves  the  OBPL  so  that  after  another  process  or  operator  associ- 
ates itself  with  the  connection  the  needed  information  will  be 
available  and  the  OBPL  can  be  expanded  further.  It  is  assumed 
that  no  deadlock  can  exist  unless  two  processes  are  associated 
with  the  connection  over  which  the  desired  message  text  can  be 
received . 

Let  PK  be  the  process  that  controls  R1.  A PMM  then  checks 
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if  PK  already  has  an  entry  in  the  OBPL  that  is  being  examined. 

If  it  doesn’t,  the  PMM  adds  its  name  to  the  OBPL  and  then  lets 
some  PMM  determine  if  PK  is  active.  If  PK  had  an  entry  in  the 
OBPL,  the  PMM  has  detected  a deadlock,  and  should  take  the  ap- 
propriate action.  Note  that  the  entry  for  PK  can  be  anywhere  in 
the  OBPL,  as  it  is  possible  that  a process  not  involved  in  the 
deadlock  may  be  waiting  to  access  a resource  controlled  by  a 
process  that  is  involved  in  the  deadlock.  If  PK  is  active,  then 
there  is  no  deadlock  and  the  OBPL  can  be  discarded.  If  PK  is 
blocked,  then  the  above  procedure  should  be  repeated,  except  PK 
should  be  used  Instead  of  PI  and  a PMM  determines  what  resource 
PK  is  waiting  for.  If  PK  represents  an  operator,  then  the  PMM 
must  save  the  OBPL  until  information  about  the  status  of  the  op- 
erator becomes  available.  A message  is  sent  to  the  operator 
stating  that  this  state  information  is  desired,  if  the  operator 
sends  message  text  to  a process,  or  if  the  operator  responds  that 
he/she  is  active,  then  all  OBPL’s  that  needed  state  information 
about  this  operator  are  discarded  since  there  is  currently  no 
deadlock.  If  the  operator  states  that  he/she  is  waiting,  then 
the  operator  connection  over  which  the  operator  is  awaiting  a 
message  must  also  be  stated.  The  process  that  can  send  the  op- 
erator the  desired  message  is  determined  from  the  connection 
name,  thus  the  PMM  now  knows  what  process  controls  the  resourvie 
the  operator  desires,  and  this  information  is  used  to  further 
expand  all  the  OBPL’s  that  needed  state  information  about  the 
operator.  If  no  OBPL’s  needed  this  information,  and  the  operator 
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volunteers  the  Information  that  he/she  is  blocked,  then  an  OBPL 
is  created  with  the  first  process  entry  representing  the  opera- 
tor . 

In  order  to  ensure  that  a PMM  sees  a consistent  set  of  state 
tables,  no  resources  get  allocated  or  released  in  the  node  of  the 
PMM  while  the  PMM  is  examining  an  OBPL.  (The  PMM  holds  exclusive 
use  of  the  state  tables  in  its  node.  The  reason  for  this  re- 
striction becomes  apparent  in  Chapter  VI  in  the  verification  of 
the  decentralized  algorithm.)  There  is  no  chance  of  a PMM  itself 
being  involved  in  a deadlock  because  it  is  the  only  process  that 
has  access  to  the  state  tables  in  its  node,  and  it  does  not  wait 
for  any  messages  or  request  access  to  any  other  database  objects. 
Resource  requests  and  OBPL’s  arriving  from  other  nodes  result  in 
subroutine  calls  to  the  PMM.  These  calls  are  handled  in  a FIFO 
sequence.  In  addition,  when  a process  or  operator  associates 
itself  with  a connection,  a PMM  is  called  to  check  if  any  OBPL’s 
have  been  saved  waiting  for  this  information.  Furthermore,  when 
an  operator  sends  message  text  to  a process  or  states  that  he/she 
is  active  or  blocked,  the  PMM  at  that  node  checks  if  any  OBPL’s 
have  been  saved  waiting  for  state  information  about  the  operator 
and  takes  the  appropriate  action. 

The  time  at  which  an  OBPL  gets  created  depends  upon  the 
optimization  of  the  deadlock  detection  scheme,  and  which  PMM 
creates  the  OBPL  depends  upon  what  scheme 

(centralized/decentralized)  is  used.  An  OBPL  can  be  created  as 
soon  as  a process  becomes  Mocked,  or  it  can  get  created  after 
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’X*  units  of  time  have  elapsed  without  the  process  gaining  access 
to  the  desired  resource.  The  latter  approach  will  be  used  with 
I the  expectation  that  normally  the  process  will  be  granted  access 

to  the  desired  resource  within  'X*  units  of  time  because  deadlock 

i 

i 

| does  not  exist.  Thus  the  overhead  involved  in  creating  and 

I expanding  an  OBPL  will  usually  be  avoided.  However,  within  the 

| body  of  this  paper,  in  the  interest  of  clarity  it  is  assumed  that 

I an  OBPL  is  created  immediately  after  it  is  determined  that  a de- 

| sired  resource  is  currently  unavailable.  It  should  be  understood 

I that  the  removal  of  this  assumption,  and  the  imposition  of  a 

delay  before  the  OBPL  gets  created,  does  not  impair  the 
effectiveness  of  the  algorithms  because  once  a deadlock  occurs, 
it  exists  until  some  type  of  recovery  action  is  initiated. 

Certain  information  must  be  available  to  the  PMM's  if  the 
OBPL’s  are  to  be  properly  expanded.  The  PMM  at  each  node  will 

maintain  a table  which  has  an  entry  for  each  process  in  its  node. 

Associated  with  each  process  entry  will  be  a list  of  all  the 
resources  to  which  the  process  currently  has  access,  and  the  name 
of  the  resource  to  which  the  process  desires  access  (if  the  pro- 
cess is  waiting).  For  each  resource  at  the  node,  the  PMM  must 
keep  information  stating  what  process  or  processes  currently  have 
access  to  that  resource,  and  what  type  of  access  they  have.  In 
addition,  a list  of  all  processes  that  are  waiting  for  access  to 
that  resource  must  be  maintained.  (The  latter  information  is 
necessary  so  that  the  resources  will  be  properly  allocated  when 
they  become  available.) 
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V.  Centralized  Approach  to  Deadlock  Detection 

A "centralized"  approach  to  deadlock  detection  in  a computer 
network  is  based  upon  the  premise  that  one  node  (the  "control" 
node)  in  the  network  will  act  as  the  center  of  activity  for  glo- 
bal resource  allocation  and  deadlock  detection.  In  order  to  re- 
duce overhead,  any  requests  for  resources  or  checks  for  deadlock 
that  can  be  handled  entirely  by  one  node  should  not  request  the 
service  of  the  control  node.  For  reasons  that  will  be  explained 
later,  the  following  description  has  not  been  refined,  and  should 
not  be  viewed  as  a working  algorithm.  The  description  presents 
some  ideas  that  could  form  the  basis  for  a practical  centralized 
approach  to  deadlock  detection. 

V.  1 Allocation  of  Resources 

A process  management  module  (PMK)  will  have  responsibility 
for  granting  access  to  a local  resource  as  long  as  no  remote 
processes  have  been  allocated  the  resource  nor  have  been  queued 
for  it.  When  these  conditions  do  not  hold,  the  control  process 
management  module  (CPMM)  (located  in  the  control  node)  will  have 
responsibility  for  granting  access  to  the  resource.  Thus  when  a 
process  desires  a remote  resource,  the  request  must  go  to  the 
CPMM.  When  a process  requests  a local  resource,  the  request  must 
go  through  the  CPMM  only  if  that  module  currently  has  responsi- 
bility for  granting  access  to  the  resource,  otherwise  the  request 
will  be  handled  by  the  local  PMM.  The  set  of  resources  for  which 
the  CPMM  grants  access  changes  dynamically.  (As  soon  as  a pro- 
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cess  requests  a remote  resource,  that  resource  becomes  a member 
of  the  centrally  managed  set  If  it  isn’t  already  a member,  and 
when  the  conditions  above  are  satisfied  again,  the  resource  is 
removed  from  the  set.)  For  each  resource  in  the  set,  the  CPMM 
maintains  a list  (in  the  global  resource  control  table)  of  all 
processes  queued  for  that  resource  plus  the  name  of  the  process 
or  processes  (in  the  case  of  shared  access)  that  have  been  al- 
located the  resource. 

There  are  essentially  three  classes  of  resource  requests  in 
this  type  of  network.  The  following  is  a list  of  the  resource 
request  classes  and  the  proper  response  to  each  type  of  request: 

1 A process  requests  a resource  at  the  same  node  as  the 
process,  and  the  local  PMM  is  responsible  for  granting 
access  rights  to  the  resource:  The  PMM  can  block  the 
process  or  give  it  the  resource.  In  either  case,  the 
PMM  can  update  the  appropriate  tables. 

2,  A process  requests  a resource  at  the  same  node,  and  the 
CPMM  has  been  given  responsibility  for  granting  access 
rights  to  the  resource:  A message  containing  the 
resource  request  must  be  sent  from  the  local  PMM  to  the 
CPMM.  The  local  PMM  will  block  the  process  until  it 
receives  notification  from  the  CPMM  that  the  desired 
access  has  been  granted.  Upon  receipt  of  the  resource 
request,  the  CPMM  will  either  grant  the  process  access 
to  the  desired  resource,  or  keep  it  blocked.  In  either 
case,  the  CPMM  updates  its  tables  to  reflect  the  state 
after  this  request  has  been  processed. 

3.  A process  requests  a resource  at  another  node:  A mes- 
sage containing  the  resource  request  must  be  sent  from 
the  local  PMM  to  the  CPMM.  The  local  PMM  will  block  the 
process  until  it  receives  notification  from  the  CPMM 
that  the  desired  access  has  been  granted.  Upon  receipt 
of  the  resource  reauest,  the  CPMM,  if  it  had  the  re- 
sponsibility for  granting  access  to  the  specified 
resource,  will  either  grant  the  process  access  to  the 
desired  resource  or  keep  it  blocked.  If  the  CPMM  did 
not  have  such  responsibility,  it  will  demand  it  from  the 
PMM  that  does,  and  then  the  CPMM  will  process  the 
request.  After  the  request  nas  been  processed,  the  CPMM 
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will  update  its  tables  appropriately. 

When  a process  reaches  a commitment  point,  the  ?ocal  PMM 
will  release  all  the  resources  that  the  process  controlled.  The 
PMM  can  then  grant  other  local  processes  access  to  the  resources 
that  were  released  and  for  which  it  has  responsibility  for 
granting  access.  If  any  resources  which  were  under  the  CPMM's 
control  were  released,  the  CPMM  will  be  notified  of  the  reaching 
of  a commitment  point  by  the  process,  end  it  will  then  grant 
other  processes  access  to  the  resources  if  any  are  queued  for 
them  and  the  rules  for  resource  allocation  permit  the  new 
assignments.  If  possible,  following  a resource  release,  the  CPMM 
will  return  responsibility  for  granting  access  to  a resource  back 
to  the  PMM  in  the  node  where  the  resource  resides. 


V. 2 Deadlock  Detection 

When  a PMM  denies  a request  for  a resource  and  blocks  a 
process,  it  then  creates  an  OBPL  with  a process  entry  for  the 
blocked  process.  It  then  expands  the  OBPL  until  1)  a deadlock  is 
detected,  2)  it  is  ascertained  that  there  is  no  deadlock,  or  3) 
the  PMM  does  not  have  enough  information  to  expand  the  OBPL  fur- 
ther (because  an  involved  process  is  waiting  for  a global 
resource,  or  a local  resource  is  controlled  by  a remote  process). 
In  the  latter  case  the  PMM  sends  the  OBPL  to  the  CPMM,  which  will 
complete  the  expansion  of  the  OBPL.  When  the  CPMM  denies  a 
request  for  access  to  a resource,  it  creates  an  OBPL  with  a pro- 
cess entry  for  the  blocked  process  and  then  expands  the  OBPL  un- 
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til  a deadlock  is  detected  or  it  is  ascertained  that  no  deadlock 
exists. 

To  expand  an  OBPL,  a PMM  uses  its  state  tables  that  were 
described  in  Chapter  IV,  and  the  CPMM  uses  its  global  resource 
tables  and  those  of  the  PMM's  in  the  network.  (How  it  obtains 
copies  of  these  tables  is  discussed  later  in  this  chapter.)  The 
method  by  which  the  PMM's  expand  an  OBPL  will  be  described  first, 
and  it  will  be  followed  by  the  method  which  is  used  by  the  CPMM. 
After  a PMM  has  created  an  OBPL,  it  acts  as  if  it  were  in  step  2 
below,  with  PN  set  to  the  name  of  the  process  which  was  just 
blocked,  and  RN  set  to  the  name  of  the  resource  for  which  PN  is 
waiting.  The  following  is  a list  of  steps  taken  by  a PMM  when 
expanding  an  OBPL: 

1.  Let  PN  be  waiting  for  resource  RN.  If  RN  is  a local 
resource,  go  to  step  2,  otherwise  go  to  step  6. 

2.  If  RN  is  controlled  only  by  local  processes,  go  to  step 
3,  otherwise  go  to  step  6. 

3.  Let  PX  be  the  process  controlling  RN.  If  PX  is  blocked, 
go  to  step  4,  otherwise  there  is  no  deadlock  and  the 
OBPL  can  be  discarded.  (If  there  are  J shared  readers 
of  RN,  repeat  this  step  once  for  each  reader.) 

4.  If  PX  is  already  contained  as  a process  entry  in  the 
OBPL,  there  is  a deadlock  and  the  PMM  must  take  appro- 
priate action.  If  PX  is  not  in  the  OBPL  then  go  to  step 

5. 

5.  Append  PX  as  a process  entry  in  the  OBPL  and  go  to  step 
1,  where  PX  is  used  in  place  of  PN. 

6.  Place  RN  into  the  resource  identification  portion  of  the 
OBPL  and  send  the  OBPL  to  the  CPMM.  Halt. 

The  CPMM  will  create  an  OBPL  when  it  denies  a request  for 
access  to  a resource.  The  only  process  entry  in  the  newly  cre- 
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ated  OBPL  is  for  the  process  whose  resource  request  could  not 
currently  be  honored.  After  a CPMM  has  created  an  OBPL,  it 
starts  in  step  1 below,  with  RN  3et  to  the  resource  whose 
unavailability  resulted  in  the  OBPL  being  created.  If  the  CPMM 
receives  an  OBPL  from  a PMM,  it  sets  RN  to  the  resource  that  was 
placed  in  the  resource  location  of  the  OBPL,  and  sets  PN  to  the 
last  process  to  be  inserted  into  the  OBPL.  The  CPMM  verifies 
that  PN  is  still  waiting  for  RN  (if  it  isn't,  either  RN  has  al- 


ready been  allocated  to  PN  or  the  CPMM  has  not  yet  received  the 


request  by  PN  for  access  to  RN,  so  there  is  currently  no  deadlock 
and  the  OBPL  can  be  discarded)  and  then  starts  in  step  1 below. 
The  following  is  a list  of  steps  taken  by  the  CPMM  when  expanding 


an  OBPL: 

1.  Let  PX  be  the  process  controlling  RN.  (If  there  are  J 
shared  readers  of  RN  then  repeat  this  step  once  for  each 
reader.)  To  find  PX,  the  CPMM  first  checks  if  RN  is  in 
the  global  resource  table.  If  it  is,  then  this  table  is 
used  to  get  PX,  otherwise  the  copies  of  the  local  tables 
for  the  node  in  which  RN  resides  are  used  by  the  CPMM. 

Go  to  step  2. 

2.  If  PX  is  blocked,  go  to  step  3,  otherwise  there  is  no 
deadlock  and  the  OBPL  can  be  discarded.  (First  check  if 
PX  is  waiting  for  a global  resource,  and  if  it  isn’t, 
then  check  the  copies  of  the  local  tables  for  the  node 
in  which  PX  resides  in  order  to  find  out  if  PY  is 
blocked  or  active.) 


3. 


If  PX  is  already  contained  as  a process  entry  in  the 
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priate  action.  If  PX  is  not  contained  in  the  OBPL,  go 
to  step  H. 


**  Append  PX  as  a process  entry  in  the  OBPL  and  go  to  step 
5,  where  PX  is  used  in  place  of  PN . 

P.  Let  PN  be  waiting  for  RN.  (If  PN  is  waiting  for  u glo- 
bal resource,  use  the  global  resource  table  to  determine 
PN,  otherwise  use  the  copy  of  the  local  tables  for  the 


node  in  which  PN  resides.)  Go  to  step  1. 

V.3  Issues  to  be  Resolved 

There  are  several  problems  with  the  algorithm  as  described 
in  the  previous  section.  A major  problem  is  determining  how  the 
CP¥*  maintains  its  copies  of  the  tables  belonging  to  the  PMM’s  in 
the  network.  One  possibility  is  to  have  each  PMM  send  a copy  of 

its  tables  to  the  CPMM  every  ’X»  units  of  time.  Another  is  to 

have  the  CPMM  request  a new  copy  of  the  tables  that  it  needs  if 
*Y’  units  of  time  (Y  may  equal  0)  have  elapsed  since  it  last 
received  a copy  of  the  desired  table.  In  either  case,  once  a 
deadlock  has  been  detected,  all  the  tables  of  the  nodes  whose 
processes  and  resources  are  involved  should  again  be  requested  by 
the  CPMM  in  order  to  verify  that  the  deadlock  exists  and  that  the 

CPMM  * a detection  was  not  a result  of  the  CPMM  looking  at  an 

inconsistent  state  of  the  network.  (Due  to  the  fact  that  the 
list  of  resources  that  are  kept  in  the  global  resource  table 
changes  dynamically,  and  the  CPMM  does  not  always  have  an  up  to 
date  copy  of  the  local  tables,  it  is  possible  that  some  needed 
information  may  be  incorrect  and  could  cause  problems  for  the 
CPMM.)  It  is  probable  that  there  are  better  and  more  reliable 
methods  of  maintaining  the  coDies  of  the  local  tables  in  the 
CPMM. 

When  the  CPMM  is  expanding  an  OBPL,  end  encounters  a process 
waiting  for  message  text  from  an  operator,  it  can  be  difficult  to 
eet  the  needed  state  information.  A method  is  needed  whereby  the 
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CPMM  can  save  the  OBPL  and  notify  the  PMM  at  the  node  in  which 
the  operator  resides,  that  this  state  information  is  desired. 

The  PMM  must  then  query  the  operator  and  send  the  CPMM  this  in- 
formation along  with  its  latest  state  tables. 

Another  problem  that  must  be  resolved  occurs  when  related 
messages  cross  between  two  nodes.  An  example  of  this  is  that  the 
CPMM  may  return  the  rights  to  grant  access  to  a resource  to  a PMM 
at  the  same  time  that  the  PMM  under  discussion  sends  a request  to 
the  CPMM  stating  that  one  of  its  processes  would  like  to  access 
that  local  resource.  Care  must  be  taken  when  designing  the 
resource  allocation  scheme  to  ensure  that  cases  like  this  will  be 
detected  and  the  desired  action  (which  in  this  case  is  granting 
the  process  access  to  the  resource)  will  occur.  In  addition, 
steps  must  be  taken  in  the  deadlock  detection  algorithm  to  ac- 
count for  and  detect  similar  problems. 

V.4  Reasons  for  not  Refining  the  Algorithm 

Several  factors  led  to  the  decision  not  to  refine  the  above 
algorithm  to  the  point  where  it  could  easily  be  proved  to  work. 

It  was  felt  that  with  all  remote  resource  requests  going  to  one 
node,  there  would  be  message  congestion  at  that  node,  plus  there 
would  be  an  extra  delay  due  to  the  fact  that  a request  must  go 
through  the  central  node  rather  than  going  directly  to  the  node 
in  which  the  desired  resource  resides.  Another  factor  that  i.  - 
f'luences  message  congestion  is  the  size  of  the  tables  that  will 
get  sent  from  the  PMM's  to  the  CPMM.  Since  database  records  may 


be  considered  resources,  these  tables  can  get  quite  large,  and  it 
would  be  preferable  to  only  send  the  CPMM  parts  of  these  tables, 
but  then  there  is  the  problem  of  deciding  which  parts  should  be 
sent,  and  what  the  CPMM  should  do  when  it  was  not  sent  enough 
information. 

When  one  node  is  used  as  the  center  of  activity  in  a net- 
work, the  network  becomes  only  as  reliable  as  that  node.  It 
would  be  possible  to  have  another  node  in  the  network  serve  as  a 
backup  to  the  CPMM  and  maintain  copies  of  the  CPMM’S  tables. 

There  would  be  a delay  in  updating  this  duplicate  copy,  and  it 
would  have  to  be  decided  how  often  the  copy  should  be  updated. 

(A  great  deal  of  overhead  is  involved  if  a message  is  sent  to  the 
"backup”  node  every  iim e the  CPMM  changed  its  tables.)  I-  would 
also  be  possible  to  reconstruct  the  CPMM's  tables  at  another  node 
by  requesting  information  from  all  other  nodes  in  the  network, 
thus  saving  the  overhead  involved  in  maintaining  the  duplicate 
copy  at  a cost  of  added  delay  if  the  control  node  were  to  become 
inoperable  for  some  reason.  In  a computer  network  it  is  desira- 
ble to  distribute  the  computing  and  to  minimize  the  overall  net- 
work problems  when  one  node  crashes.  This  was  the  major  reason 
it  was  decided  not  to  spend  time  refining  an  algorithm  for 
deadlock  detection  which  relies  upon  one  node  in  the  network. 
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VI.  Decentralized  Approach  to  Deadlock  Detection 

A "decentralized”  approach  to  deadlock  detection  in  a com- 
puter network  is  based  upon  the  premise  that  there  should  be  no 
central  or  control  node  and  that  all  nodes  in  the  network  will 
share  the  responsi  >ility  for  detecting  deadlocks.  In  addition, 
the  failure  of  one  node  should  only  affect  the  processes  of  that 
node  and  the  processes  of  other  nodes  which  are  accessing  that 
node’s  resources.  The  amount  of  duplicate  process  and  resource 
state  information  among  the  various  nodes  in  the  network  will  be 
kept  to  a minimum,  and  each  node  will  he  requested  to  help  check 
for  a deadlock  only  when  at  least  one  of  its  processes  or 
resources  is  involved. 

VI. 1 Allocation  of  Resources 

A process  management  module  ( PMM)  located  at  each  node  will 
always  have  responsibility  for  granting  access  to  resources  lo- 
cated at  that  node.  Whenever  a process  requests  a resource,  the 
request  will  be  processed  by  the  PMM  at  the  same  node  as  the 
process.  This  PMM  will  determine  if  the  desired  resource  is  lo- 
cal or  if  it  is  located  at  a different  node.  (Message  text 
should  be  treated  as  local  to  the  node  of  the  sending  process.) 

If  it  is  a local  resource,  then  the  PMM  can  immediately  determine 
if  the  desired  access  may  be  granted  or  if  the  process  must  be 
blocked  waiting  for  the  availability  cf  the  resource.  If  the 
request  is  for  a remote  database  object,  then  the  PMM  must  block 
the  process  and  send  a remote  database  object  request  (RDOR)  to 
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the  PMM  in  the  node  which  contains  the  desired  resource.  Upon 
receipt  of  an  RDOR  from  another  node,  a PMM  will  determine  if  the 
requesting  process  must  remain  bioeKed  or  if  it  may  be  granted 
access  to  the  desired  resource.  If  access  is  granted,  a remote 
database  object  assignment  (RDOA)  is  sent  to  the  PMM  in  the  node 
in  which  the  requesting  process  resides.  Upon  receipt  of  this 
RDOA,  the  PMM  will  awaken  the  proper  process  and  notify  it  of  the 
resource  assignment.  If  the  process  must  remain  blocked,  no 
message  is  sent  to  the  node  in  which  the  process  resides.  The 
details  of  implementing  this  feature  are  not  described,  as  they 
are  not  relevant  to  the  scope  of  this  Thesis. 

When  a process  reaches  a commitment  point,  the  PMM  at  its 
node  will  release  all  the  database  resources  that  the  process  had 
access  to  and  notify  the  necessary  processes  that  no  more  mes- 
sages are  forthcoming  from  the  specified  process.  All  local 
resources  can  be  immediately  allocated  to  other  processes  in  ac- 
cordance with  the  rules  for  resource  allocation,  and  messages 
must  be  sent  to  all  nodes  which  had  resources  allocated  to  the 
process,  informing  their  PMM's  of  the  reaching  of  a commitment 
point.  Upon  receipt  of  such  a message,  the  PMM  will 
appropriately  update  its  tables  and  assign  the  resources  to  other 
processes  in  accordance  with  the  rules  for  resource  allocation. 

VT.2  Deadlock  Detection 

When  a PMM  determines  that  a resource  at  its  node  can  not 
currently  be  allocated  to  a process  that  requested  it,  the  PMM 
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creates  an  OBPL  (ordered  blocked  process  list)  with  a process 
entry  for  the  blocked  process.  It  then  expands  the  OBPL  until  1) 
a deadlock  is  detected,  ?)  it  is  ascertained  that  there  is  no 
deadlock,  or  3)  the  PMM  does  not  have  enough  information  to  fur- 
ther expand  the  OBPL.  (Note  that  if  a database  object  has  been 
requested,  the  OPPL  is  created  in  the  node  where  the  database 
object  resides,  whereas  if  message  text  has  been  requested,  the 
OBPL  is  created  in  the  node  where  the  requesting  process 
resides.)  The  PMM  starts  expanding  the  newly  created  OBPL  in 
steo  10  below.  When  a PMM  receives  an  OBPL  from  another  node,  it 
starts  in  step  1 below  in  on  attempt  to  complete  the  expansion  of 
the  OBPL.  The  reasoning  behind  each  step  is  contained  in  the 
next  section,  and  these  explanations  should  be  read  before  one 
attempts  to  verify  the  correctness  of  the  algorithm.  It  should 
be  noted  that  within  the  algorithm,  PX  and  RX  are  names  of  vari- 
ables whose  contents  represent  processes  and  resources,  respec- 
tively, even  though  they  are  sometimes  used  as  though  they  were 
process  and  resource  names  themselves. 

1.  Set  RX  to  the  value  contained  in  the  resource 
identification  portion  of  the  OBPL.  If  RX  represents  a 
resource  which  is  local  to  the  node  expanding  the  OBPL, 
then  go  to  step  2,  otherwise  go  to  step  8. 

2.  Verify  that  the  last  process  added  to  the  OBPL  is  still 
waiting  for  RX.  If  it  isn’t  then  discard  the  OBPL  and 
halt,  otherwise  go  to  step  3. 

1.  Let  PX  be  the  process  controlling  RX.  (If  there  are  J 
shared  readers  of  RX,  then  repeat  this  step  once  for 
each  reader.)  If  PX  already  has  a process  entry  in  the 
OBPL,  then  there  is  a deadlock  and  the  PMM  must  take  the 
appropriate  action.  If  PX  is  not  in  the  OBPL  then  go  to 
step 
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4.  If  PX  represents  a process  which  is  local  to  the  node 
expanding  the  OBPL,  then  go  to  step  5,  otherwise  go  to 
step  7. 

5.  If  PX  is  active,  there  is  no  deadlock,  so  discard  the 
OBPL  and  halt.  Otherwise  go  to  step  6. 

6.  Append  PX  as  a process  entry  in  the  OBPL  and  go  to  step 

10. 

7.  Append  PX  as  a process  entry  in  the  OBPL.  Place  RX  into 
the  resource  identification  portion  of  the  OBPL  and  send 
the  OBPL  to  the  PMM  in  the  node  in  which  PX  resides. 
Halt. 

B.  Verify  that  the  last  process  added  to  the  OBPL  still  has 
access  to  RX.  If  it  doesn’t,  discard  the  OBPL  and  halt. 
Otherwise  go  to  step  9. 

9.  If  the  last  process  added  to  the  OBPL  is  active,  there 
is  no  deadlock,  so  discard  the  OBPL  and  halt.  Otherwise 
go  to  step  10. 

10.  Get  the  name  of  the  resource  for  which  the  last  process 
added  to  the  OBPL  is  waiting  and  call  it  RY.  If  RX 
represents  a resource  which  is  local  to  the  node 
expanding  the  OBPL,  go  to  step  3,  otherwise  go  to  step 
11. 

11.  Place  RX  into  the  resource  identification  portion  of  the 
OBPL  and  send  the  OBPL  to  the  PMM  in  the  node  in  which 
RX  resides.  Halt. 


VI. 3 Explanation  of  Steps  In  the  Deadlock  Detection  Algorithm 

The  following  is  a description  of  the  reasons  for  including 

each  step  in  the  deadlock  detection  algorithm  described  in  the 

previous  section.  Each  numbered  paragraph  below  corresponds  to 

the  step  with  the  same  number  in  the  previous  section. 

1.  An  OBPL  will  be  sent  t,o  a node  when  it  must  be  deter- 
mined what  process  controls  a given  resource,  or  what 
state  (active  or  blocked)  a given  process  is  in.  If  the 
resource  that  was  named  in  the  resource  identification 
portion  of  the  OBPL  is  local  to  the  node  that  just 
received  the  OBPL,  then  in  order  to  expand  the  OBPL  the 
PMM  needs  to  know  what  process  has  access  to  that 
resource  and  it  goes  to  step  P,  otherwise  it  goes  to 
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step  8 in  order  to  check  the  state  of  the  last  process 
to  be  added  to  the  OBPL. 

It  must  be  verified  that  the  last  process  added  to  the 
OBPL  is  still  waiting  for  RX  because  it  is  possible  that 
while  the  OBPL  was  sent  from  the  PMM  in  the  node  con- 
taining the  process,  the  PMM  in  the  node  containing  RX 
sent  a message  stating  that  the  process  has  been  granted 
access  to  RX.  If  this  process  is  no  longer  waiting  for 
RX,  the  state  that  was  assumed  when  the  OBPL  was  sent  no 
longer  exists,  and  the  OBPL  can  be  discarded. 

If  RX  represents  a database  object,  then  the  last  pro- 
cess added  to  the  OBPL  is  still  waiting  for  RX  if  it  is 
still  queued  for  access  to  the  database  object.  If  RX 
represents  a message  in  a message  group,  then  RX  is 
qualified  by  the  sequence  number  of  the  message  within 
the  message  group  that  is  desired.  (If  the  process  has 
already  received  N messages  over  the  specified  connec- 
tion, then  it  is  waiting  for  message  number  N+1  in  the 
message  group.)  The  process  is  still  waiting  for  the 
specified  message  only  if  the  number  of  messages  already 
sent  to  it  over  the  given  connection  is  less  than  the 
number  that  qualified  the  message  group  name. 

If  PX  already  has  a process  entry  in  the  OBPL,  then 
there  is  a loop  of  processes  each  waiting  for  a resource 
that  is  controlled  by  the  next  process  in  the  loop,  so  a 
deadlock  has  been  detected.  If  PX  does  not  have  a pro- 
cess entry  in  the  OBPL,  go  to  step  *1  in  order  *-o  expand 
the  OBPL  further  if  PX  is  not  active. 

If  RX  is  a database  object  which  has  J shared  readers, 
then  a copy  of  the  OBPL  must  be  made  for  each  of  these 
readers  because  the  process  that  requested  access  to  RX 
will  not  be  able  to  access  RX  if  the  process  is  in  a 
deadly  embrace  Iood  involving  any  one  of  the  J readers. 

If  PX  is  local  to  the  node  which  is  expanding  the  OBPL, 
then  the  PMM  can  immediately  check  the  state  of  PX,  so 
it  goes  to  step  5.  If  PX  is  not  a local  process,  the 
OBPL  must  be  sent  to  the  node  in  which  PX  resides,  so 
the  PMM  goes  to  step  7. 

If  PX  is  not  currently  blocked  waiting  for  access  to  any 
resources,  there  can  be  no  deadlock  currently  involving 
PX.  If  PX  represents  an  operator,  the  OBPL  must  be 
queued  waiting  for  state  information  about  the  operator. 
The  PMM  will  then  ask  the  operator  to  enter  information 
about  his/her  state.  The  acceptable  operator  responses 
are  V)  that  he/she  is  waiting  for  a message  over  a given 
operator  connection,  ?)  that  he/she  is  active,  or  7)  a 


regular  message  over  an  operator  connection.  If  the 
operator  sends  a regular  message,  or  states  that  he/she 
is  active,  then  there  is  no  deadlock  and  all  the  OBPL*s 
that  are  queued  for  state  information  about  this  opera- 
tor will  be  discarded.  If  the  operator  states  that 
he/she  is  waiting  for  a message,  then  the  PMM  can  (by 
the  use  of  the  given  operator  connection)  determine  what 
process  can  send  the  message  that  the  operator  desires, 
and  the  PMM  can  then  further  expand  the  OBPL.  It  may  be 
desirable  to  "time  out"  a non-responsive  operator,  as 
operator  inaction  can  stall  the  system  and  perpetuate  an 
undetected  deadlock. 

6.  PX  is  blocked,  so  insert  it  as  the  last  entry  in  the 
OBPL  and  then  go  to  step  10  in  order  to  further  expand 
the  OBPL. 

7.  Insert  PX  as  the  last  entry  in  the  OBPL  even  though  the 
PMM  does  not  know  the  state  (active  or  blocked)  of  PX. 
(This  will  be  checked  by  the  node  that  will  receive  the 
OBPL.)  Place  RX  into  the  resource  identification 
portion  of  the  OBPL  to  indicate  that  PX  currently  con- 
trols RX,  and  the  state  of  PX  is  needed  information.  If 
RX  represents  a message  within  a message  group,  it  is 
qualified  by  the  sequence  number  of  the  message  within 
the  message  group  that  is  desired.  The  PMM  therefore 
sends  the  OBPL  for  further  expansion  to  the  PMM  in  the 
node  which  contains  PX. 

R.  It  must  be  verified  that  the  last  process  added  to  the 
OBPL  still  has  access  to  RX  because  it  is  possible  that 
while  the  OBPL  was  sent  from  the  PMM  in  the  node  con- 
taining RX,  the  PMM  in  the  node  containing  the  process 
sent  a message  stating  that  RX  has  been  released  by  the 
process.  If  the  process  no  longer  has  access  to  RX  then 
the  state  that  was  assumed  when  the  OBPL  w a;  sent  no 
longer  exists,  and  the  OBPL  can  be  discarded. 

d.  If  the  last  process  added  to  the  OBPL  is  not  currently 
blocked  waiting  for  access  to  any  resources,  there  can 
be  no  deadlock  currently  involving  the  process.  If  the 
process  is  blocked,  the  PMM  goes  to  step  10  because  the 
process  already  has  been  inserted  as  the  last  process 
entry  in  the  OBPL. 

10.  Step  10  can  be  reached  from  step  6 or  step  9.  In  either 
case,  the  last  process  added  to  the  OBPL  is  local  to  the 
node  which  is  expanding  the  OBPL,  so  the  PMM  can  find 
out  what  resource  the  process  desires  access  to.  Set  RX 
to  the  name  of  this  resource.  If  RX  is  local  to  the 
node  that  is  currently  expanding  the  OBPL,  the  PMM  can 
continue  to  expand  the  OBPL,  so  it  goes  to  step  1, 


otherwise  it  goes  to  step  11. 


11.  To  further  expand  the  OBPL,  what  process  has  access  to 
RX  must  be  known,  so  the  PMM  sends  the  OBPL  to  the  PHH 
in  the  node  in  which  RX  resides.  Place  RX  into  the 
resource  identification  portion  of  the  OBPL  to  indicate 
that  the  last  process  added  to  the  OBPL  is  blocked 
waiting  for  access  to  RX  and  what  process  controls  RX  is 
needed  information.  In  the  ease  where  RX  represents  .a 
message  within  a message  group,  it  is  qualified  by  the 
sequence  number  of  the  message  within  the  message  group 
that  is  desired.  Send  the  OBPL  for  further  expansion  to 
the  node  in  which  RX  resides. 


VI. 4 Verification  of  the  Algorithm 

There  are  two  parts  in  the  verification  of  the  correctness 
of  the  decentralized  algorithm  for  deadlock  detection.  The  first 
and  most  important  part  is  to  prove  that  all  deadlocks  get 
detected.  The  second  part  is  proving  that  a deadlock  is  not 
"detected"  when  (except  in  a special  case  discussed  later)  one 
does  not  exist. 


Part  1 

To  prove  that  all  deadlocks  get  detected,  it  will  be 
shown  that  once  a deadlock  3tate  Is  reached,  an  OBPL  will  be 
created  that  will  be  passed  among  nodes  which  will  expand  it 
until  the  deadlock  is  detected.  There  are  two  assumptions 
that  are  required  for  this  proof:  1)  All  internodal  mes- 
sages eventually  get  received  by  the  proper  nodes  (and 
therefore  no  OBPL's  are  "lost"  in  the  transmission  between 
nodes),  and  2)  while  the  OBPL  is  being  expanded,  none  of  the 
processes  involved  in  the  deadlock  are  aborted  (which  would 
break  the  deadlock  before  it  is  detected)  or  rolled  back  to 
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a previous  state  (which  would  imply  the  deadlock  has  been 
detected  by  the  expansion  of  another  OBPL),. 

Let  a deadlock  consist  of  processes  PI,  P 2,  PN, 

with  PI  waiting  for  a resource  controlled  by  P2,  and  PN 

waiting  for  a resource  controlled  by  PI.  (Process  r<ame3  are 
unique  within  a node  and  they  can  be  made  network  unique  by 
qualifying  them  with  their  node  names,  so  throughout  this 
proof,  assume  the  Pi  represent  distinct  processes.)  When 
each  process,  Pi,  involved  in  the  deadlock  was  denied  access 
to  a resource  controlled  by  another  process  in  the  deadlock, 
an  OBPL  was  created  with  the  first  process  entry  represent- 
ing Pi.  One  of  these  OBPL’s  mu3t  have  been  the  last  (in 
time)  to  be  created,  thus  the  deadlock  existed  at  that  time. 
(If  two  or  more  of  these  OBPL’s  were  created  simultaneously 
and  they  were  the  last  to  be  created  for  processes  involved 
in  the  deadlock,  then  any  one  in  this  "last  group”  may  be 
arbitrarily  selected  as  the  last  to  be  created.  The 
important  point  is  that  the  deadlock  existed  at  the  time  the 
OBPL  was  created,  and  all  the  relevant  tables  collectively 
contain  the  information  showing  each  process  in  the  deadlock 
waiting  for  a resource  controlled  by  another  process  in  the 
deadlock.)  For  simplicity,  assume  that  this  last  OBPL  con- 
tains PI  as  its  first  process  entry.  Additionally,  in  the 
ensuing  discussion,  a messag®  from  an  operator  to  a 
computerized  process  will  not  be  treated  as  a special  type 
of  resource  because  it  is  assumed  that  operators  "111  state 


what  they  are  waiting  for  when  asked  to  do  so  by  a PMM. 

After  PI  has  been  inserted  as  the  first  process  entry 
in  this  "last"  OBPL,  the  PMM  which  will  begin  the  expansion 
of  the  OBPL  will  be  in  step  10  of  the  algorithm.  If  PI  is 
waiting  for  access  to  a resource  local  to  a different  node, 
then  the  PMM  executes  steps  10  and  11,  and  another  PMM 
(after  receipt  of  the  OBPL)  executes  steps  1 and  2,  then 
goes  to  step  3*  otherwise  the  PMM  executes  step  10  ind  goes 
to  step  3.  (Since  there  is  a deadlock,  the  OBPL  will  not  be 
discarded.)  Now,  no  matter  what  PI  is  waiting  for,  it  can 
be  assumed  that  a PMM  is  about  to  start  step  3 and  it  can 
(i.e.  it  has  the  information  in  its  tables)  dete-mine  what 
process  (in  this  case,  P2)  controls  the  resource  PI  has  re- 
quested. There  are  two  ways  (depending  on  whether  P2  is 
local  or  global  to  the  nock  in  which  the  OBPL  is  currently 
located)  in  which  a process  entry  for  P2  will  be  inserted 
into  the  OBPL. 

Case  A:  P2  is  "local". 

Steps  4,  5 and  6 are  executed,  then  step  10  will  be 
executed.  The  PMM  will  then  be  ready  to  execute  step  3 
or  it  will  execute  step  11  and  another  PMM  will  execute 
steps  1 and  2,  and  will  be  prepared  to  execute  step  3. 

Case  B:  P2  is  "global". 

Steps  *1  and  7 are  executed,  then  the  PMM  which  then 
receives  the  OBPL  will  execute  steps  1,  8,  9 and  10. 

It  will  then  be  ready  to  execute  step  3 or  it  wili  ex- 
ecute step  11  and  another  PMM  will  execute  steps  1 and 
?,  and  will  be  prepared  to  execute  step  3- 

This  "last"  OBPL  now  has  process  entries  for  PI  and  P2, 

and  a PMM  is  about  to  execute  step  3 to  continue  the 


expansion  of  the  OBPL.  A PMM  is  now  essentially  in  the  same 
position  some  PMM  was  in  shortly  after  the  OBPL  was  created. 
The  only  difference  is  that  now  two  processes  have  entries 
in  the  OBPL,  and  RX  is  set  to  the  resource  for  which  P2  is 
waiting,  rather  than  the  resource  for  which  PI  is  waiting. 

By  repeating  the  above  procedure  as  many  times  as  necessary, 
the  OBPL  will  be  expanded  to  include  process  entries  for 
processes  PI,  P2,  ...,  PN.  At  this  point,  when  step  3 is 
executed,  it  will  be  determined  that  PI  controls  the 
resource  PM  has  requested,  and  the  deadlock  will  be 
detected . 

QED  Part  1. 


Part  2 

To  prove  that  every  deadlock  that  gets  "detected”  ac- 
tually is  a deadlock,  it  must  be  shown  that  an  OBPL  will  be 
discarded  whenever  there  is  a change  in  the  state  that  was 
assumed  when  a process  entry  was  made  in  that  OBPL.  (The 
one  exception,  which  is  ignored  in  the  ensuing  discussion, 
is  the  case  where  the  assumed  state  changes  due  to  the 
aborting  or  rolling  back  of  a process,  rather  than  having 
the  state  change  due  to  a waiting  process  being  awakened  and 
granted  access  to  the  resource  for  which  it  was  waiting.) 
This  condition  is  sufficient  because  if  a deadlock  is 
"detected"  when  expanding  the  OBPL  containing  (in  order  of 
insertion)  process  entries  for  PI,  P2,  . 
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PM,  PN,  and 


there  has  been  no  change  in  the  state  that  was  assumed  when 
each  process  was  entered  into  the  OBPL,  then  PI  is  still 
waiting  to  access  a resource  controlled  by  P2,  . ..,  PH  is 
still  waiting  to  access  a resource  controlled  by  PN,  and  PN 
is  still  waiting  to  access  a resource  controlled  by  PJ, 
where  PJ  appears  earlier  in  the  OBPL.  Thus  a deadlock  ac- 
tually exists  if  one  is  "detected"  and  there  has  been  no 
change  in  the  state  that  was  assumed  when  the  process  en- 
tries were  inserted  into  the  OBPL. 

Assume  that  a PMM  is  expanding  an  OBPL  with  process 
entries  (in  order  of  insertion)  PI,  P2,  ...,  PK,  PL.  If  the 
algorithm  is  correct,  then  PI  is  waiting  for  access  to  a 
resource  controlled  by  P2,  and  PK  waiting  for  access  to 

a resource  controlled  by  PL.  Now  assume  that  this  state 
does  not  hold.  That  is  to  say,  for  some  Pi,  Pj  with  adjac- 
ent process  entries  in  the  OBPL,  either  Pi  is  not  waiting 
for  access  to  the  same  resource  (say  RQ)  for  which  it  was 
waiting  when  it  was  ascertained  that  Pi  was  blocked  and  that 
Pi  should  have  an  entry  in  the  OBPL,  or  Pj  no  longer  con- 
trols RO.  It  will  be  shown  that  whenever  this  situation 
occurs,  it  will  be  detected  and  the  OBPL  will  be  discarded. 

It  can  he  assumed  that  Pi  and  Pj  are  PK  and  PL  respec- 
tively, because  if  tne  state  has  changed  from  what  was  as- 
sumed when  Pi  was  inserted  into  the  OBPL,  then  it  either 
changed  before  a PMM  checked  to  see  what  Pj  was  waiting  for, 
Pj  was  not  blocked,  or  the  state  changed  after  there  was  a 


similar  state  change  involving  Pj  and  the  next  process  in 
the  list.  (The  latter  claim  can  be  made  because  if  Pi  was 
waiting  for  access  to  RQ  which  was  controlled  by  Pj,  and  Pj 
controlled  RQ  and  was  blocked  at  the  time  that  it  was 
decided  to  further  expand  the  OBPL,  the  only  way  the  assumed 
state  could  change  would  be  for  Pj  to  incur  a state  change 
and  be  awakened  so  that  it  could  release  RQ.) 

In  order  to  show  that  PK  is  still  waiting  for  RQ,  and 
that  RO  is  still  controlled  by  PL  whenever  it  is  decided 
that  another  process  should  be  added  tc  the  OBPL,  two  cases 
must  be  considered.  1)  PL,  PK  and  RQ  are  all  located  in  the 
same  node,  and  2)  PL,  PK  and  RQ  are  located  in  two  or  three 
different  nodes  in  the  network. 

Case  1. 


Due  tc  the  restriction  that  operators  can  only 
communicate  with  processes,  there  are  three  possible 
combinations  of  the  types  (process  or  operator)  of  PL 
and  PK.  (The  resource  type  of  RQ  is  either  unimportant 
or  uniquely  determined  by  PK  and  PL.) 

Case  A:  PK  and  PL  are  both  processes. 

Once  PK  has  been  inserted  into  the  OBPL,  and  the 
PMM  in  the  node  in  which  PK  resides  is  expanding 
the  OBPL,  the  PMM  determines  that  PK  is  waiting 
for  access  to  RQ  and  that  PL  controls  RQ.  It  then 
inserts  PL  into  the  OBPL  if  PL  is  blocked  anu 
discards  the  OBPL  if  PL  is  active.  Since  the  PMM 
has  exclusive  use  of  the  state  tables  in  its  node, 
there  is  no  way  the  assumed  state  will  change  un- 
til after  the  OBPL  is  discarded,  sent  to  another 
node  or  queued  waiting  for  state  information  about 
an  operator  (in  which  case  the  state  can  not 
change  until  after  the  operator  states  that  he/she 
is  active  or  sends  a message  to  a process,  both  of 
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| which  result  in  ,he  OBPL  being  discarded). 

| Case  B:  PK  is  an  operator  and  PL  is  a process. 

| PK  is  not  inserted  into  the  OBPL  until  the  opera- 

tor states  that  he/she  is  waiting  for  a message 
| over  a given  operator  connection  (RQ).  The  PMM  in 

i the  node  in  which  PK  resides  then  determines  that 

! PL  is  the  process  that  can  send  the  desired  mes- 

j sage.  If  PL  is  blocked,  it  is  inserted  into  the 

j OBPL,  otherwise  the  OBPL  is  discarded.  Since  the 

PMM  has  exclusive  control  of  the  state  tables  in 
; its  node,  the  assumed  state  csn  not  change  until 

| after  the  OBPL  is  discarded,  sent  to  another  node, 

or  queued  waiting  for  state  information  about  an 
operator . 

Case  C:  PK  is  a process  and  PL  is  an  operator. 

PL  is  not  inserted  into  the  OBPL  until  the  opera- 
tor states  that  he/she  is  waiting  for  a message 
over  a given  operator  connection.  PK  is  still 
waiting  for  a message  from  PL  because  the  OBPL 
would  have  been  discarded  if  any  message  text  had 
been  received  from  the  operator  since  the  OBPL  was 
queued  waiting  for  state  information  about  the 
operator.  (Note  that  it  is  possible  that  the  de- 
sired message  may  have  been  sent  by  the  operator 
before  the  OBPL  was  queued,  but  it  has  not  been 
given  to  PK  because  calls  to  the  PMM  are  processed 
in  a first  in,  first  out  fashion.  In  this  case 
though,  the  OBPL  will  be  discarded  before  any 
state  message  from  the  operator  is  processed,  be- 
cause the  desired  message  text  was  sent  before  the 
operator  state  message.)  The  OBPL  will  then  ei- 
ther be  discarded  or  have  another  process  entry 
added  to  it,  because  an  operator  can  only  wait  for 
a message  from  a process  located  at  the  same  node. 


Case  ?. 

Whenever  an  OBPL  is  sent  between  nodes,  it  must  be 
verified  that  the  state  that  was  assumed  when  the  OBPL 
was  sent  is  still  valid.  Operators  do  not  cause  any 
OBPL's  to  be  sent  between  nodes  (because  they  only 
communicate  with  processes  at  their  own  nodes),  thus  in 
this  discussion  PK  and  PL  are  always  processes.  There 
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are  four  combinations  of  the  resource  type  of  RO  and 
the  locations  of  PK,  PL  and  RQ. 

Case  A:  RQ  is  a database  object  located  in  the  same 
node  as  PK,  but  different  from  PL. 

After  it  is  ascertained  that  PK  is  blocked  waiting 
for  access  to  RO,  it  is  determined  that  PL  con- 
trols RQ.  PL  is  then  inserted  into  the  OBPL 
(after  the  entry  for  PK)  and  the  OBPL  is  sent  to 
the  PMM  in  the  node  in  which  PL  resides.  When  the 
PMM  receives  the  OBPL,  it  first  verifies  that  PL 
still  controls  RO.  If  it  doesn't,  there  has  been 
a change  in  the  assumed  state  (PL  has  released 
KQ),  and  the  OBPL  is  discarded.  Note  that  the 
OBPL  is  also  discarded  if  it  is  determined  that  PL 
is  not  blocked. 

Case  B:  RO  is  a database  object  located  in  the  same 
node  as  PL,  but  different  from  PK. 

After  it  is  ascertained  that  PK  is  blocked  waiting 
for  access  to  RQ,  the  OBPL  is  sent  to  the  PMM  in 
the  node  in  which  RO  and  PL  reside.  Upon  receipt 
of  the  OBPL,  this  PMM  verifies  that  PK  is  still 
waiting  for  access  to  RO.  If  it  isn't,  there  has 
been  a state  change  (PK  was  granted  access  to  RQ) , 
and  the  OBPL  is  discarded.  The  OBPL  is  also 
discarded  if  it  is  determined  that  PL  (which  con- 
trols RO)  is  not  blocked. 

Case  C:  RQ  is  a database  object  located  in  a node 
which  contains  neither  PK  nor  PL. 

After  it  is  ascertained  that  PK  is  blocked  waiting 
for  access  to  RQ,  the  OBPL  is  sent  to  the  PMM  in 
the  node  in  which  RO  resides.  Upon  receipt  of  the 
OBPL,  this  PMM  verifies  that  PK  is  still  waiting 
for  access  to  RO.  If  it  isn't,  there  has  been  a 
state  change,  and  the  OBPL  is  discarded.  If  PK  is 
still  waiting  for  access  to  RO,  then  the  PMM  in- 
serts PL  into  the  OBPL  (since  PL  controls  RO)  and 
sends  the  OBPL  to  the  PMM  in  the  node  in  which  PL 
resides.  After  the  OBPL  is  received,  the  PMM  then 
checks  that  PL  still  controls  RQ.  If  it  doesn't, 
there  has  been  a change  in  the  assumed  state,  and 
the  OBPL  is  discarded.  The  OBPL  is  also  discarded 
if  it  is  determined  that  PL  is  not  blocked. 

Case  D:  RQ  represents  message  text  and  PK  and  PL  are 
located  in  different  nodes. 

After  PK  is  inserted  into  the  OBPL  because  the 
process  is  waiting  for  message  text  in  message 
group  RO,  RQ  is  qualified  by  a message  number. 
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The  OBPL  is  then  sent  to  the  node  in  which  PL 
resides.  PL  will  only  be  inserted  into  the  OBPL 
if  it  is  blocked  and  the  specified  message  has  not 
been  sent  (which  implies  PK  is  still  in  the  state 
it  was  in  when  it  was  inserted  into  the  OBPL), 
otherwise  the  OBPL  will  be  discarded. 

It  has  been  shown  that  whenever  the  relevant  portions 
of  the  overall  network  state  differ  from  the  state  that  was 
assumed  when  process  entries  were  inserted  into  the  OBPL, 
the  situation  is  detected  and  the  OBPL  is  discarded. 
Therefore  it  is  impossible  to  detect  anything  but  deadlocks 
since  a deadlock  is  never  "detected"  unless  a PMM  wants  to 
insert  a process  into  an  OBPL  when  there  is  already  a pro- 
cess entry  in  the  OBPL  for  that  process.  It  has  thus  been 
proven  that  the  decentralized  algorithm  only  "detects" 
deadlocks. 

QFD  Part  2. 

OFP  Oecentrallzed  Algorithm. 

VT.5  Some  Properties  of  the  Algorithm 

It  should  be  noted  that  all  references  to  processes  in  the 
previous  sections  actually  referred  to  process  "commitment  units" 
(the  period  between  commitment  points),  and  the  fact  that 
commitment  units  within  a process  are  network  unique  allows  a 
deadlock  to  be  detected  at  a node  different  from  the  one  which 
contains  the  process  that  was  found  to  already  have  a process 
entry  in  an  ORPL.  This  situation  can  arise  if  the  process  under 
discussion  controls  a remote  database  object,  and  the  PMM  at  the 
node  in  which  the  database  object  resides  wants  to  insert  the 


60 


process  into  the  OBPL  due  to  its  controlling  the  above  mentioned 
database  object.  The  OBPL  need  not  be  sent  to  the  PMM  in  the 
node  in  which  the  process  resides  to  verify  that  the  process 
still  controls  the  database  object,  because  the  process  has  not 
reached  a commitment  point  (by  virtue  of  the  fact  it  already  has 
an  entry  in  the  OBPL)  and  therefore  has  not  released  any  d tabase 
objects. 

All  resource  requests  will  be  handled  with  minimal  delay 
because,  for  any  request,  the  only  nodes  involved  are  those  which 
contain  the  associated  process  and  resource.  (No  information  is 
needed  from  any  other  nodes  to  process  the  request.)  The  algo- 
rithm will  function  properly  regardless  of  the  resource 
allocation  scheme  in  use,  since  the  needed  information  about  a 
resource  is  what  process  (or  processes)  currently  controls  it, 
not  the  order  in  which  processes  will  be  granted  access  to  the 
resource  in  the  future.  (The  latter  information  is  necessary 
only  for  deadlock  avoidance  algorithms.) 

While  a PMM  is  expanding  an  OBPL,  all  other  PMM’s  may  be 
processing  resource  requests  and  releases.  A PMM  need  only  see  a 
consistent  state  within  its  own  node  in  order  to  expand  an  OBPL. 
The  restriction  that  a PMM  can  not  process  resource  requests  and 
releases  while  it  is  expanding  an  OBPL  can  be  removed  if  the 
decentralized  algorithm  is  modified  slightly.  In  step  10  the 
branch  to  step  3 would  be  eliminated  (and  therefore  always  go  to 
step  11  after  step  10),  and  then  in  step  11  a PMM  may  send  an 
OBPL  to  itself.  The  new  restriction  would  be  that  no  resource 
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requests  or  releases  can  be  processed  while  a PMM  is  executing 
steps  1 through  11,  although  resource  requests  and  releases  could 
he  processed  between  the  execution  of  step  11  and  step  1. 

The  same  deadlock  can  be  detected  more  than  once  if  pro- 
cesses and  resources  located  in  two  or  more  nodes  are  involved. 
This  situation  will  occur  if  two  or  more  processes  request 
request  resources  at  approximately  the  same  time,  resulting  in 
OBPL’s  being  created  starting  with  different  processes  in  the 
same  deadlock  loop.  It  is  important  to  note  that  no  matter  how 
long  it  t8kes  for  OBPL's,  remote  resource  requests,  remote 
resource  assignments,  message  text  in  message  groups,  and  noti- 
fication of  a remote  process  termination  to  travel  between  nodes, 
the  algorithm  still  functions  as  expected  due  to  the  verification 
steps  that  a*"e  included  and  the  fact  that  once  a deadlock  exists, 
it  will  not  be  broken  until  after  it  .is  detected  and  recovery 
action  is  initiated. 
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VII.  Af)T  Model  of  the  Decentralized  Algorithm 
A functional  model  of  the  decentralized  algorithm  described 
in  the  previous  chapter  was  designed  and  created  using  the 
facilities  of  the  Architectural  Definition  Technique  (ADT).  The 
model  was  designed  so  that  the  algorithm  could  be  easily  tested. 
Additionally,  by  designing  the  model  at  the  same  time  that  the 
algorithm  was  being  refined,  several  deficiencies  of  early  ver- 
sions of  the  algorithm  were  detected  and  corrected.  (See  section 
VII.?  and  [1?  for  information  about  ADT.) 

The  model  was  written  in  PL/I  and  runs  on  the  Honeywell 
Multics  timesharing  system.  It  was  coded  for  ease  of  use  and 
readability,  and  is  not  intended  to  suggest  the  most  efficient 
way  of  implementing  the  algorithm  in  a computer  network.  A pre- 
requisite to  the  use  of  ADT  is  an  ability  to  understand  the  con- 
cept behind  Data  Structure  Diagrams. 


VII. 1 Data  Structure  Diagrams 

An  information  structure  can  be  described  by  a Data  Struc- 
ture Diagram.  A particuisr  object  in  an  information  structure  is 
referred  to  33  an  "entity”,  and  an  entire  group  of  similar  enti- 
ties is  called  an  ’’entity-class” . (They  are  characterized  by  a 
vrototype  called  an  ”enti ty-fcype” . ) The  grouping  that  associates 
one  or  more  entities  of  the  same  entity-class  with  one  entity  of 
a second  entity-class  (same  or  different  type)  in  a subordinate 
relationship  is  known  as  an  ’’entity-set".  In  a Data  Structure 
Diagram,  a block  is  used  to  represent  an  entity-type  (the 
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entity-type  name  is  written  inside  the  block).  A "set-class"  is 
a collection  of  similar  entity-sets.  (They  are  characterized  by 
a prototype  called  a "set-type".)  An  arrow  represents  a 
set-type.  It  designates  (by  pointing  from)  the  entity-type  that 
"owns"  the  set-type  and  designates  (by  pointing  to)  the 
entity-type  that  serves  as  the  "members”  of  the  set. 

There  is  a 1 to  n relationship  between  the  owner  and  members 
of  an  entity-set:  n may  be  zero,  one  or  more.  For  each  owner 
there  may  be  any  number  of  members,  but  for  each  member,  there  is 
only  one  owner  in  any  set  occurrence.  A dashed  arrow  is  used  to 
represent  a set-type  where  the  member  relationship  may  or  may  not 
exist.  This  is  called  a "sometime”  member  relationship.  When 
there  can  be  only  one  member  in  an  entity-set,  a line  (rather 
than  arrow)  is  drawn  between  the  owner  entity-class  and  member 
entity-class.  A dashed  line  is  used  when  there  can  be  a sometime 
one-to-one  relationship. 

A situation  can  arise  where  a set-type  can  have  more  than 
one  type  of  entity  in  the  member  role.  In  this  case  a multihead 
arrow  is  used  to  represent  the  set-type.  Similarly,  a multi^ail 
arrow  is  used  to  represent  a set-type  where  more  than  one  type  of 
entity  can  assume  the  owner  role  (although  each  member  has  only 
one  owner).  A more  detailed  explanation  of  Data  Structure 
Diagrams  can  be  found  in  [?"!• 

VII.?  Architectural  Definition  Technique 

APT  is  an  approach  to  arriving  at  a complete,  concise, 


non-ambiguous  functional  specification  of  a software  or  hardware 
system  which  is  totally  independent  of  packaging  considerations. 
To  use  ADT,  one  must  describe  the  system  state  variables  in  terms 
of  occurrences  of  entity-types,  attribute  types  and  set-types, 
and  create  a user  interface  as  a set  of  machine  processable 
function  definition  algorithms. 

An  example  of  an  entity-type  is  "node"  in  a computer  net- 
work. Each  node  in  the  network  must  have  a name,  which  is  an 
attribute  of  the  entity.  The  entity-type  and  its  attributes  must 
be  declared.  In  addition,  all  entity-sets  which  a node  may 
belong  to  as  a member  or  owner  must  be  declared,  and  the  rela- 
tionship ("member”,  "owner",  or  "recursive")  must  be  stated.  A 
node  is  a member  of  the  set  of  all  nodes  in  a network,  but  it  is 
the  owner  of  various  resources  and  processes  located  at  that 
node.  The  manner  in  which  entities  and  their  attributes  and  set 
relationships  are  represented  in  the  machine  is  irrelevant  to  the 
goal  of  achieving  a functional  specification.  Therefore  the  ADT 
user  is  relieved  of  this  burden. 

A function  definition  algorithm  is  a body  of  code  which 
specifies  what  action  3hould  take  place  in  response  to  a given 
external  stimulus.  A function  definition  algorithm  has  several 
responsibilities.  1)  It  must  validate  the  input  parameters,  2) 

It  must  execute  the  logic  of  the  function,  3)  It  must  access  the 
system  state  tables  and  update  them  appropriately  to  reflect  the 
action  taken,  and  M)  It  must  provide  an  external  response  repre- 
senting the  action  (or  lack  thereof)  that  has  taken  place.  A 


function  definition  algorithm  usually  includes  a series  of  calls 
to  the  ADT  modelling  subroutines. 

One  integral  part  of  ADT  is  a set  of  procedures  which  faci- 
litate the  modelling  of  the  "system  state".  These  procedures 
provide  the  capability  to  create  and  maintain  a network 
structured  database  which  holds  the  entities,  attributes  and  re- 
lationships used  to  model  the  system. 

A functional  model  created  using  ADT  can  be  exercised  and 
"validated"  by  the  creation  and  execution  of  a sequence  of 
commands.  (Calls  to  the  various  function  definition  algorithms.) 
Any  number  of  commands  can  be  executed  so  that  the  model  can  be 
observed  in  order  to  determine  if  it  acts  in  accordance  with 
expectations. 

Facilities  are  furnished  in  ADT  to  save  these  sequences  of 
commands  (scenarios)  and  to  automatically  execute  them.  There 
are  also  facilities  so  that  the  system  state  can  be  saved  and 
restored.  Display  facilities  are  provided  which  permit  a de- 
tailed examination  of  the  system  state  without  altering  it. 

Using  these  facilities  it  is  easy  to  construct  experiments,  alter 
them  and  examine  the  results  at  any  time. 

ADT  is  a deterministic  system,  and  the  machine  is  always  in 
a stable  state  during  the  period  between  calls  to  the  various 
function  definition  algorithms. 

VIT.?  The  Deadlock  Detection  Model 

The  deadlock  detection  model  which  runs  using  ADT  was  de- 


signed  to  te  driven  entirely  by  the  user  of  the  model.  Ail  the 
nodes  in  the  network  must  be  created  by  the  model  user,  as  are 
processes  and  database  resources  located  at  each  node.  In  addi- 
tion all  operators  at  each  node  must  be  declared.  Each  node  in 
the  network  must  have  a unique  name.  Operator  names  and  process 
names  appear  together  in  the  same  name  space  and  must  be  unique 
within  each  node.  They  are  qualified  by  the  node  name  to  make 
them  unique  in  the  network.  Database  objects  must  also  have 
unique  names  within  the  set  of  database  objects  at  a node. 

Process  wait  situations  may  arise  as  a result  of  requests 
for  message  text  in  a message  group  or  over  an  operator  connec- 
tion, or  requests  for  access  to  a database  object,  but  operator 
wait  situations  are  not  forced  by  the  system  because  operators  do 
not  request  message  text,  they  only  take  it  as  it  comes  over  an 
operator  connection.  All  requests  by  processes  for  resources 
must  be  entered  by  the  model  user.  The  model  will  process  the 
requests,  and  allocate  the  desired  resources,  if  possible, 
otherwise  the  requesting  process  will  be  blocked.  When  message 
text  is  requested,  the  message  group  name  (in  the  case  of  process 
to  process  communication)  or  operator  connection  name  (for  oper- 
ator to  process  >mmunication)  must  be  given.  With  the  model, 
before  message  text  in  a message  group  can  be  received  by  a 
nrr»r»*j«« , the  rcrcogc  group  muol  first  be  initiated  by  tne  process 
which  can  send  the  messages,  and  then  be  accepted  by  the  process 
that  will  receive  the  messages  in  the  message  group.  (The  mode) 
user  specifies  when  this  takes  place.)  Aotua1  systems  nay  allow 


message  groups  to  be  accepted  by  a process  before  another  process 
initiates  it.  An  operator  connection  must  be  established  'by  the 
model  user)  between  an  operator  and  a process  at  the  same  node 
before  a process  can  receive  message  text  over  the  operator  con- 
nection. This  model  does  not  support  the  sending  of  messages 
from  a process  to  an  operator  over  an  operator  connection  because 
typically  messages  from  a process  to  an  operator  are  not  queued 
for  receipt  by  an  operator,  they  are  simply  printed  at  the 
operator’s  terminal  without  an  explicit  operator  requett. 

In  ord?r  to  make  the  model  easier  to  use,  it  was  decided  to 
make  message  group  names  and  operator  cc  nectlon  names  unique 
within  the  network. 

In  a computer  network  it  is  probable  that  message  text  may 
be  sent  by  either  process  involved  in  a connection  through  which 
they  are  communicating.  (This  is  a two-way  connection.'  The 
model  only  allows  the  initiator  of  a message  gi  o*rp  to  send  mes- 
sage text  over  the  associated  connection  because  a two-way  con- 
nection can  be  simulated  using  two  one-way  connoctions , witn  each 
process  involved  being  the  initiator  of  one  of  the  message 
groups.  The  sender  and  receiver  of  message  text  in  a message 
group  are  thus  uniquely  determined  by  the.  message  f.rcup  nee, 
therefore  the  model  user  need  not  type  a process  nams  wh  n 
causing  action  to  be  taken  to  simulate  the  sending  or  receivi'/ 
of  message  text.  (Similarly,  the  sender  and  receive-*  of  menage 
tdxt  over  an  operator  connection  are  uniquely  determined  because 
the  model  only  allows  message  text  to  go  f**om  the  operator  to  the 


associated  process.) 

Each  node  will  need  to  maintain  some  information  about  the 

other  nodes  in  the  network.  (It  needs  to  know  about  remote  pro- 

cesses that  have  requested  access  to  at  least  one  of  its 
resources,  and  it  needs  some  information  about  remote  resources 
that  have  been  requested  by  at  least  one  of  its  processes.)  The 

model  is  designed  to  create  a set  of  node  tables  (one  table  for 

each  node  in  the  network)  at  each  node  in  the  network.  Each  node 
will  use  its  set  of  node  tables  to  maintain  the  information  it 
needs  about  all  the  nodes  in  the  network. 

Control  messages  are  used  by  the  model  to  simulate  the 
transmission  of  most  types  of  internodal  messages.  When  a mes- 
sage must  be  sent  between  nodes,  the  model  will  cause  text  to  be 
printed  at  the  model  user’s  terminal  giving  the  model  control 
message  number  and  stating  the  destination  node  and  what  the 
message  represents.  At  the  time  the  model  user  would  like  the 
destination  node  to  receive  the  message,  he/she  must  issue  a 
command  to  the  model  to  receive  the  associated  control  message. 
ORPL's,  message  text  within  message  groups,  and  resource 
allocation  messages  are  all  sent  between  nodes  via  control 
messages.  This  mechanism  was  selected  so  that  the  effect  of 
internodal  messages  being  delivered  with  varying  delays  could  be 
•Hwiiii  at-Arf  tha  only  internodal  n.cosdge  chat  tne  model  allows  to 
be  processed  without  user  intervention  is  the  one  that  would  be 
associated  with  the  initiating  of  a message  group.  There  is  no 
need  to  model  the  delay  of  a message  for  this  because  the  node  in 
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which  the  accepting  process  of  the  message  group  resides  must  be 
aware  of  the  initiation  before  any  checks  for  deadlock  involving 
that  message  group  will  be  made. 

The  types  of  resource  allocation  messages  that  may  r«ss  be- 
tween nodes  are  1)  requests  for  access  to  remote  database 
objects,  2)  notification  that  a process  has  been  granted  access 
to  a previously  requested  database  object,  and  3)  notification 
that  a process  has  released  a database  object.  If  the  model  user 
enters  a process  request  for  a remote  database  object,  the  model 
will  block  the  process  and  send  a control  message  (representing  a 
remote  resource  request)  to  the  node  in  which  the  desired 
database  object  resides.  (Since  deadlock  detection  is  being 
modelled,  and  resource  allocation  need  not  be  completely 
simulated,  the  model  first  looks  across  nodes  to  verify  that  the 
requested  database  object  exists  before  it  ser.ds  the  control 
message.)  After  this  control  message  is  received  and  the  desired 
database  object  can  be  allocated  to  the  aforementioned  process,  a 
control  message  stating  that  the  process  has  been  allocated  the 
desired  resource  is  sent  to  the  node  in  which  the  process 
resides.  When  this  new  control  message  is  received,  the  process 
will  be  awakened.  Although  the  release  of  database  objects  is 
not  necessary  to  test  ar,  algorithm  for  deadlock  detection,  a 
command  to  allow  a process  to  release  a single  database  object 
was  included  in  the  model  for  debugging  purposes.  When  a process 
releases  a remote  database  object,  a control  message  is  sent  to 
the  node  in  which  the  database  object  resides.  The  model  does 
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not  simulate  the  automatic  release  of  all  resources  controlled  by 
a process  at  the  time  the  process  reaches  a commitment  point. 

This  is  a feature  of  process  and  resource  management,  and  is  not 
relevant  to  the  simulation  of  a deadlock  detection  algorithm. 

In  order  to  create  deadlock  situations,  processes  must  be 
able  to  gain  control  of  some  database  objects.  The  model  uses  a 
first-in-first-out  allocation  scheme  for  database  objects.  A 
process  will  be  blocked  if  1)  it  requests  any  type  of  access  to  a 
database  object  that  has  been  exclusively  assigned  to  another 
process,  2)  it  requests  any  type  of  access  to  a database  object 
which  already  has  other  processes  waiting  for  access  to  it,  or  3) 
it  requests  exclusive  use  of  a database  object  and  some  process 
currently  has  access  to  the  desired  database  object. 

In  order  to  adhere  to  the  belief  that  the  model  should  be  as 
simple  as  possible,  the  model,  in  expanding  an  OBPL,  does  not  u.se 
the  decentralized  algorithm  exactly  as  described  in  the  previous 
chapter.  In  step  10,  the  branch  to  step  3 was  removed,  thus  step 
11  is  always  executed  after  step  10.  When  step  11  sends  an  OBPL 
to  the  node  in  which  it  is  already  located,  further  expansion 
takes  place  immediately.  Steps  1 and  ? then  get  executed 
unnecessarily  because  RX  is  properly  set  in  step  10,  and  the 
state  tables  have  not  been  changed  during  the  expansion  of  the 


Appendix  I contains  a Data  Structure  Diagram  for  the 
deadlock  detection  model,  plus  a description  of  the  entities  and 
relationships  shown  in  the  Diagram.  Appendix  II  contains  a brief 
description  of  all  the  user  visible  functions  in  the  model,  fol- 
lowed by  the  PL/I  code  of  the  function  definition  algorithms 
which  define  the  model. 

VII. 4 Test  Cases  run  on  the  Model 

Using  the  model,  several  deadlock  and  near  deadlock 
situations  were  entered  to  demonstrate  various  features  of  the 
deadlock  detection  algorithm.  A feature  of  the  ADT  system  allows 
a user  to  save  a series  of  command*  in  a file,  and  then  type 
"scenario  <file  name>"  to  have  the  commands  executed  in  order. 

In  each  of  the  cases  given,  after  the  system  was  reinitialized, 
but  before  the  commands  specific  to  each  example  were  executed, 
the  commands  in  file  "demoO"  were  executed.  The  files,  along 
with  the  output  that  resulted  from  the  commands  in  the  files, 
appear  in  Appendix  III.  The  scenarios  are  well  annotated,  and  it 
should  be  noted  that  commands  to  the  system  appear  flush  with  the 
margin,  whereas  output  from  the  Deadlock  Detection  Model  is 
indented . 

The  deadlocks  created  range  from  one  involving  two  processes 
and  two  resources  located  in  a single  node,  to  some  involving 
,v,g re  than  five  processes  or  ope*"a,'r'r<  r.han  four 

resources  located  throughout  a three  node  network.  By  creating 
the  same  deadlock,  but  altering  the  order  in  which  processes  get 
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blocked  and  the  order  in  which  internodal  messages  are  allowed  to 
arrive,  it  is  shown  that  the  number  of  times  the  same  deadlock  is 
detected  depends  on  how  close  (in  time)  some  processes  in  the 
deadlock  get  blocked,  and  on  the  locations  of  the  various  pro- 
cesses and  nodes.  (The  model  works  properly  regardless  of  the 
"simultaneous"  processing  of  commands  at  various  nodes.)  Appen- 
dix III  also  includes  state  diagrams  for  the  test  cases  which 
appear  in  that  Appendix.  For  the  cases  where  a deadlock  is  cre- 
ated, only  the  final  state  is  drawn  (a  key  to  understanding  the 
diagrams  is  included),  whereas  lor  the  cases  where  there  is  no 
deadlock,  an  Important  interim  state  is  included  in  addition  to 
the  final  state. 

The  restriction  stated  in  Chapter  4 that  a process  can  not 
gain  access  to  a database  object,  release  it  and  request  it  again 
before  reaching  a commitment  point,  was  included  to  rule  out  the 
situation  that  is  shown  in  "demo_bug".  (The  scenario  was 
included  for  demonstration  purposes  only.) 


VIII.  Suggestions  for  Further  Research 
After  a deadlock  is  detected,  at  least  one  involved  process 
must  be  forced  to  rescind  its  request  for  a resource  that  is 
controlled  by  another  process  involved  in  the  deadlock.  Some  of 
the  problems  involved  in  breaking  a deadlock  (in  particular  when 
the  deadlock  is  detected  using  the  decentralized  algorithm 
presented  in  Chapter  VI)  are  discussed  below,  as  are  some  issues 
that  may  lead  to  modifications  in  the  schemes  presented  in 
Chapters  V and  VI. 

VIII.  1 The  Rollback/Retry  Problem 

In  order  to  break  a deadlock  situation,  at  least  one  process 
involved  in  the  deadlock  must  be  selected  and  be  forced  to 
rollback  (backup)  to  a state  prior  to  the  time  at  which  it  re- 
auested  access  to  the  resource  for  which  it  was  waiting  when  the 
deadlock  was  detected.  If  the  algorithm  presented  in  Chapter  VI 
is  being  used  to  detect  deadlocks,  then  (due  to  the  restriction 
that  a process  cannot  release  a database  object  when  it  is  be- 
tween commitment  points)  the  process  selected  for  rollback  must 
be  returned  to  its  most  recent  commitment  point.  In  rolling  back 
the  process,  the  external  effects  created  since  the  last  process 
commitment  point  must  he  cancelled. 

To  accomplish  this  rollback,  it  is  necessary  to  undo  all 
udi.ai'asc  uujeul  u j mJ aUo  that  the  process  pspfr“*med  fithir 
scope  of  its  current  commitment  unit  (the  period  since  its  most 
recent  commitment  point),  and  then  release  all  the  database  ob- 
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jects  that  were  assigned  to  the  process.  In  addition,  all  items 
of  message  text  that  were  sent  by  the  process  in  this  commitment 
unit  must  be  taken  back,  and  all  items  of  message  text  that  were 
received  by  the  process  in  this  commitment  unit  must  be  requeued 
over  the  proper  connections  so  that  they  may  again  be  properly 
received  after  the  process  resumes  execution.  When  taking  an 
item  of  message  text  back,  if  it  had  already  been  received  by  the 
destination  process,  this  destination  process  must  also  be  rolled 
back  to  its  most  recent  commitment  point. 

Research  needs  to  be  performed  to  determine  an  efficient 
method  for  rolling  back  a process.  It  is  possible  that  some 
constraints  may  have  to  be  placed  upon  communicating  processes  in 
order  to  simplify  the  rollback  problem  and  lessen  the  amount  of 
information  about  a process  that  must  be  retained  between 
commitment  points.  Some  papers  have  been  published  that  deal 
with  the  problem  of  rolling  back  a database  to  a previous  state. 
(See  m for  one  example.) 

Use  of  the  deadlock  detection  algorithm  described  in  Chapter 
VI  can  result  in  the  same  deadlock  being  detected  more  than  once. 
It  therefore  may  be  useful  to  develop  a deterministic  algorithm 
for  deciding  which  process  should  be  rolled  back,  so  that  addi- 
tional processes  are  not  rolled  back  unnecessarily.  Note  that  if 
nrrL's  are  created  immediately  after  a process  gets  blocked,  then 
every  deadlock  will  be  detected  with  an  OBPL  that  contains  only 
the  involved  processes.  Thus  even  though  a process  not  involved 
in  a particular  deadlock  may  be  waiting  for  access  to  a resource 
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which  has  been  assigned  to  a process  in  the  deadlock,  no  action 
need  be  taken  when  the  deadlock  is  detected  using  an  OBPL  which 
contains  more  than  the  involved  processes.  One  possibility  is  to 
impose  an  arbitrary  ordering  on  the  nodes  in  the  network,  and 
always  rollback  a process  in  the  lowest  numbered  node  that  is 
involved  in  a given  deadlock.  This  method  is  unfair  in  the  sense 
that  processes  in  the  higher  numbered  nodes  will  rarely  be  forced 
to  rollback  to  a previous  state.  Perhaps  a fairer  method  is  to 
attach  a cost  factor  to  each  process  entry  in  an  OBPL.  This  cost 
factor  will  represent  the  cost  (for  the  associated  process)  of 
computation  to  date  in  that  process  commitment  unit.  The  process 
with  the  lowest  cost  factor  will  be  rolled  back  with  the  hope 
that  this  minimizes  the  overall  network  cost  of  breaking  the 
deadlock.  It  is  also  possible  that  when  the  same  deadlock  is 
detected  more  than  once,  it  may  be  cheaper  (from  the  overall 
network  cost  viewpoint)  to  rollback  an  extra  process 
occasionally,  than  to  add  the  extra  overhead  that  is  needed  for 
the  methods  mentioned  above.  This  is  a topic  which  needs  to  be 
studied  further. 

Another  related  topic  which  can  be  investigated  involves 
relaxing  some  of  the  restrictions  dealing  with  the  release  of 
database  objects  so  that  a process  can  be  rolled  back  to  a state 
somewhere  between  the  previous  commitment  point  and  the  deadlock 
state.  This  may  involve  slight  modifications  to  the  algorithm 
described  in  Chapter  VI,  but  may  be  useful  because  l€3S  code  will 
have  to  be  r&executed  after  rollback.  (It  may  be  particularly 
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worthwhile  when  a process  is  executing  a section  of  code  where  it 
is  sequentially  requesting  access  to  several  database  objects 
before  reading  or  updating  any  of  them.  Thus  a partial,  and 
perhaps  sufficient  rollback  could  be  accomplished  by  the  release 
of  some  of  the  database  objects.) 

VIII. 2 Optimization  and  Expansion  of  the  Decentralized  Algorithm 
If  OBPL’s  are  created  after  a process  has  been  blocked  for 
'X ’ units  of  time  (with  'X'  greater  than  0),  then  it  may  be  pos- 
sible to  occasionally  eliminate  the  need  to  create  an  OBPL  after 
a given  process  has  been  blocked  for  • X * units  of  time.  When  a 
process  is  inserted  into  an  OBPL  before  it  has  been  blocked  for 
'X'  units  of  time,  the  need  to  create  an  OBPL  with  this  process 
as  the  first  entry  is  eliminated.  (Additionally,  the  process  may 
be  granted  access  to  the  desired  resource  before  *X'  units  of 
time  have  elapsed,  also  eliminating  the  need  to  create  an  OBPL.) 
This  type  of  Implementation  would  affect  the  scheme  used  to  break 

\ 

| deadlocks,  as  there  would  no  longer  be  the  guarantee  that  each 

$ 

| deadlock  would  be  detected  with  an  OBPL  that  only  contains  pro- 

v, 

f cess  entries  for  the  involved  processes. 

i A restriction  presented  in  Chapter  IV  prevents  a process 

from  requesting  shared  access  to  a database  object  and  then 
reauesting  exclusive  use  of  the  same  rtatahas*  ^hji»/>t . It  may  be 
possible  to  allow  this  situation  will  little  modification  to  the 
decentralized  algorithm. 

The  algorithm  presented  in  Chapter  VI  requires  that  all 
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resources  be  uniquely  identifiable.  It  may  be  desirable  in  some 
applications  to  allow  processes  to  wait  for  any  one  of  N 
identical  and  interchangeable  resources.  Inclusion  of  this 
property  would  necessitate  a change  in  the  use  and  expansion  of 
OBPL’s.  Preliminary  study  shows  that  it  would  be  necessary  to 
place  control  of  the  expansion  of  an  OBPL  with  one  node  (which 
may  be  different  for  each  OBPL) , since  notification  would  be  re- 
quired after  it  is  ascertained  that  a loop  exists  in  an  OBPL  or 
that  an  active  process  has  been  encountered.  This  notification 
is  needed  because  there  is  a deadlock  involving  N identical 
resources  only  if  every  process  that  controls  one  of  these 
resources  is  involved  in  a loop  in  an  OBPL.  (This  is  in  contrast 
to  the  situation  where  there  are  N readers  of  a given  database 
object  and  a deadlock  exists  if  any  one  of  these  readers  is 
involved  in  a loop  in  an  OBPL.)  Rather  than  passing  an  OBPL  from 
node  to  node,  the  "controlling”  node  may  request  other  nodes  to 
expand  a section  of  the  OBPL  and  return  it  to  the  "controlling" 
node.  Further  study  is  required  to  determine  exactly  how  the 
decentralized  algorithm  can  be  modified  to  include  the  above 
mentioned  feature. 

In  addition,  it  may  be  worthwhile  to  study  the  possibilities 
of  allowing  human  processes  to  wait  for  events  external  to  the 
computer  system  (i.e.  a phone  call  or  a message  from  a fellow 
worker,  rather  than  only  wait  for  a message  from  a given  process) 
and/or  the  possibilities  of  allowing  a process  to  wiit  for  more 
than  one  resource  at  a tima. 
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VIII. 3 Types  and  Probability  of  Deadlock 

In  order  to  get  a valid  estimation  of  the  cost  of  using  the 
deadlock  detection  algorithm  presented  in  Chapter  VI,  it  is  nec- 
essary to  get  estimations  as  to  how  many  processes  in  how  many 
different  nodes  are  typically  involved  in  e deadlock,  and  how 
frequently  deadlock  can  be  expected  to  occur.  Some  research  has 
been  performed  dealing  with  the  probability  of  deadlock  in  a 
computer  system  (see  f 6 3 ) , but  to  this  author's  knowledge,  no 
work  has  been  performed  dealing  with  the  types  (i.e.  how  many 
processes  in  how  many  different  nodes)  of  deadlock  that  can  be 
expected  in  a computer  network. 

VIII. *5  Refinement  of  the  Centralized  Algorithm 

The  scheme  presented  in  Chapter  V was  not  studied 
extensively.  It  Is  possible  that  it  can  be  refined  to  a point 
where  little,  if  any,  unnecessary  processing  takes  place  in  order 
to  determine  if  a deadlock  exists.  Due  to  reliability  factors 
and  communications  delays,  it  is  not  recommended  that  a 
centralized  scheme  be  used  exclusively  in  a network.  However,  u 
hybrid  model  of  the  centralized  and  decentralized  algorithms  mny 
orove  to  be  more  cost  effective  than  the  decentralized  algorithm 
alone.  This  hybrid  model  could  possibly  be  constructed  by  using 
the  centralized  scheme  for  small  ktouds  of  nodes  located  within  a 
specified  distance  of  each  other,  and  then  using  tie 
decentralized  scheme  between  the  control  nodes  for  each  of  the 
groups  using  the  centralized  scheme. 


IX.  Conclusions 

The  schemes  presented  in  Chapters  II  and  III  were  designed 
to  be  used  to  help  detect  process  deadlocks  in  a computer  network 
where  the  only  allowable  wait  condition  is  for  the  availability 
of  database  resources.  Many  systems  only  allow  this  type  of  I 

process  wait,  so  there  is  a need  for  algorithms  which  solve  the  j 

problems  that  the  schemes  of  Chapters  II  and  III  attack.  \ 

However,  some  alterations  must  be  made  to  the  scheme  of  Chandra, 

Howe  and  Karp  and  to  the  decentralized  scheme  of  Mahmoud  and 
Riordon  before  they  can  be  used  to  solve  the  problems  they 
address.  It  seems  that  these  two  schemes,  when  modified,  would 
result  in  essentially  the  same  algorithm.  This  new  algorithm 
would  require  each  node's  resource  tables  to  be  sent  to  one  node 
in  the  network,  which  will  then  process  all  the  outstanding 
requests  for  access  to  database  objects.  (In  the  case  of  Mahmoud 
and  Riordon's  scheme,  perhaps  each  node  would  still  examine  all 
requests.)  The  major  difference  from  the  original  schemes  is 
that  no  resource  allocations  would  be  performed  without  examining 
the  entire  network  state,  (i.e.  requests  for  access  by  a process 
to  local  resources  must  still  wait  for  information  from  other 
nodes)  With  or  without  modifications,  the  two  schemes  are 
inefficient  In  that  they  require  large  tables  (when  the  database 
is  locked  at  the  record  level)  to  ne  passed  between  the  nodes. 

'Additionally,  each  node  must  be  capable  of  processing  requests 
which  require  the  uresenoe  of  every  node's  tables  in  that  node. 

This  is  an  undesirable  constraint,  because  it  requires 
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minicomputers  which  serve  as  nodes  within  the  network  to  have  the 
capacity  to  store  (in  main  memory  or  secondary  storage)  the 
entire  network  state  at  one  time.  Although  only  minor  modifica- 
tions are  required  to  the  schemes  so  that  they  will  work,  they 
may  require  some  major  modifications  before  they  can  be  used  in  a 
general  scheme  for  detecting  deadlock  in  all  types  (i.e.  any  size 
computers  and  any  number  of  nodes)  of  computer  networks. 

The  two  "centralized”  schemes  presented  in  Chapters  III  and 
V can  both  result  in  message  bottlenecks  at  the  control  node,  and 
if  the  control  node  fails,  both  result  in  a significant  delay 
while  a new  control  node  is  established.  Additionally,  if  the 
network  is  geographically  spread  out,  there  can  be  an  undesirable 
delay  in  some  cases  when  a process  requests  access  to  a local 
database  object.  It  is  recommended  that  neither  scheme  be  used 
exclusively  in  a network  which  covers  a large  (geographically) 
area  or  consists  of  a large  numbe**  of  nodes. 

The  decentralized  algorithm  presented  in  Chapter  VI  requires 
each  node  to  only  maintain  information  relating  to  its  processes 
and  resources.  Thus  the  amount  of  storage  required  at  each  node 
to  support  the  algorithm  is  proportional  to  the  total  size  of  the 
system  at  that  node.  Additionally,  there  is  little,  if  any. 
delay  in  granting  a process  access  to  an  available  resource. 

Tue  size  of  messages  (OBPL's)  passed  between  the  node<?  i «* 
directly  proportional  to  the  number  of  processes  involved  in  a 
chain,  where  each  process  is  waiting  for  a resource  controlled  by 
another  process  in  the  chain.  It  is  felt  that  these  chains  (and 
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therefore  OBPL’s)  each  Involve  only  a few  processes,  and  by 
delaying  the  creation  of  OBPL’s  until  after  a process  has  been 
backed  for  units  of  time,  the  number  of  OBPL’s  that  must  be 
passed  between  nodes  will  be  minimal.  It  should  be  noted  that 
the  decentralized  algorithm  presented  in  Chapter  VI  will  work 
regardless  of  whether  or  not  processes  are  allowed  to  wait  for 
messages  which  must  oe  sent  from  other  processes  within  the  net- 

\ 

work . 


With  the  optimization  feature  discussed  earlier,  the  algo- 
rithm presented  in  Chapter  VI  is  efficient  and  can  be  use 
regardless  of  the  size  and  composition  of  a computer  network. 
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Data  Structure  Diagram  for  the  ADT  Deadlock  Detection  Model 


Appendix  I 


Entity  Descriptions 


This  section  describes  the  entities  which  are  used  in  the  ADT  Deadlock 
Detection  Model.  Each  entity  is  described  in  basically  the  sane  manner.  The 
format  used  is: 


<ENTITY  NAME> 
<text 


> 


entity  attributes: 
attribute  name> 
<text 


> 


entity  owner  roles: 

<nane  of  set  owned  by  entity> 

<text 

> 

entity  member  roles: 

<»am«  of  set  where  entity  is  a mamber> 

The  sets  are  named  in  the  following  way: 

owner_name->aember_jname 

Both  cwr.srjr«ase  and  mpniuij'  naac  are  the  names  or  entities.  A Qualifier  is 
used  to  distinguish  between  two  sets  which  have  the  same  entities  a::  owner  and 
member: 

owner,  name- >aenber_jname  ( quail  fler ) 

If  there  are  alternate  owners  or  multiple  members,  the  notation  used  is: 

owner.nane/owner  name/. . .->nember_nane/member_name/. . . Where  attribute 
names  are  used,  they  correspond  exaotly  to  the  names  (which  Include  abbrevia- 
tions for  the  entitles  they  represent)  that  are  used  in  the  PL/I  code  of  the 
Model. 


DATABASEjOBJBCT 

This  represents  an  object  within  the  database  which  is  subject  to  exclusive 
(read/write)  or  shareable  (read  only)  access  control.  The  object  may  be  of 
various  levels  of  granularity  (file,  page,  record,  or  item  of  record'.  The 
only  requirement  is  that  the  entire  object  is  treated  uniformly  in  regard 
to  assignment  to  a process  and  subsequent  release. 

entity  attributes: 
dbo.name 

The  unique  name  for  the  database  object  at  the  node  in  which  it 
resides. 

entity  owner  roles: 

database_object->database_obJeot_shared_assignment 

The  set  of  shared_assignment  entities  for  a database  object  defining 
the  number  of  processes  current1 y sharing  the  database  object  on  a 
read  only  basis. 

database_object->proces3 

The  set  of  processes  waiting  on  the  availability  of  the  database  ob- 
ject. 

( see  node_table/dbo/message_group/operator_connection->process) 
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entity  member  roles: 

node_table->database_object 

process->database_object 

DATABASE_OBJECT_SHA  RED_ASSIGNMENT 

The  mechanism  for  recording  the  shared  assignment  of  a database  object  to  a 
process  for  read  only  purposes. 

entity_attributes:  (none) 

entity  owner  roles:  (none) 

entity  member  roles: 

database_objeet->database_c!:jeot_shared_asalgnment 

process->database_object_shared_assignment 

MESSAGEJ3R0UP 

The  string  of  text  elements  which  are  sent  from  one  prooess  to  another  over 
a specified  oonneotion. 

entity  attributes: 

message .name 

The  network  unique  name  for  the  message  group, 
message .numbered 

The  number  of  messages  in  the  oes&iige  group  that  have  been  received 
by  the  acceptor  of  the  message  grou.  plus  the  number  of  messages  that 
are  currently  queued  at  the  destination  end  and  have  not  yet  been 
reoeived. 


message . number_rc vd 

The  number  of  messages  in  the  message  group  that  have  been  received 
(read)  by  the  acceptor'  of  the  message  group. 

message . number_sent 

The  number  of  messages  in  the  message  group  that  have  been  sent 
(regardless  of  whether  or  not  they  have  currently  reached  the  desti- 
nation  node)  by  the  initiator  of  the  message  group. 

entity  owner  roles: 

mea3age_jgroup->process 

The  set  of  processes  waiting  for  text  in  the  message  group.  The  na- 
ture of  exclusive  assignment  of  a message  group  to  a process 
precludes  more  than  one  process  to  actually  be  waiting  for  text. 

( see  node_tuble/dbo/message,group/operalor_oonneotlon->process) 

entity  member  roles: 

node_table->message_group( accept) 

node_table->message_group(init.) 

procesa->message_group{ receive) 

process->message_group( send) 

system->message_group 

MESSAGE_TEXT 

This  represents  one  message  within  a message  group  when  the  initiator  .and 
acceptor  are  located  in  different  nodes,  no  actual  text  need  be 
transmitted,  because  for  the  purposes  of  deadlock  detection,  the  content  of 
the  messages  is  unimportant,  and  it  is  onlv  neoessor/  to  know  how  many 
messages  are  sent  and  received. 
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Entity  Descriptions 


entity  attributes: 
aag.mgnaae 

The  message  group  naae  to  which  the  "simulated  message"  belongs. 

entity  owner  roles:  (none) 

entity  member  roles: 
system->oess«ge_text 


NODE 

A processor  in  the  network  which  includes  a Process  Management  Module  for 
the  purposes  of  resource  allocation  and  deadlook  detection. 

entity  attributes: 
node. naae 

The  network  unique  name  for  the  node. 

entity  owner  roles: 
node->node_table 

The  set  of  tables  used  by  a node  to  maintain  all  needed  Information 
about  the  nodes  in  the  network. 

entity  member  roles: 
syatem->node 

MAHVI  M«M(  V* 

nv/i/cwiAOiifi 

A table  used  to  maintain  needed  information  about  operators,  processes  and 
resources  located  at  a given  node. 

entity  attributes: 
node  table. name 

The  nrjje  of  the  node  about  which  this  table  will  maintain  informa- 
tion. 

entity  owner  roles: 

node  table->database_object 

The  set  of  database  objects  located  in  the  node  "referenced"  by  the 
node  table,  and  for  which  the  node  in  which  the  node  table  resides 
needs  information. 

node  table->measage_Jgroup( accept) 

The  set  of  message  groups  that  have  been  initiated  with  the  accepting 
prooess  declared  to  be  located  in  the  node  which  is  "referenced"  by 
the  node  table,  and  located  therein.  (If  a node  table  does  not 
"reference"  the  node  in  which  it  is  located,  then  this  set  is  empty 
for  that  node  table.) 

node  table- >measage_jgroup(  init) 

The  set  of  message  groups  that  have  been  initiated  by  processes  lo- 
cated in  the  node  which  is  "referenced"  by  the  node  table,  and  lo- 
cated therein.  (If  a node  table  does  not  "reference"  the  node  in 
which  it  is  located,  then  this  set  is  empty  for  that  node  table.) 

node  table- >operator 

The  set  of  operators  declared  to  exist  at  the  node  "referenced"  by 
the  node  table,  and  for  which  the  node  in  which  the  node  table  re- 
sides needs  information.  (A  node  only  needs  tc  know  about  tho  oper- 
ators at  its  own  node,  therefore  if  a node  table  noes  not  "reference" 
the  node  in  which  it  is  located,  this  set  is  empty  for  that  node 
table. ) 

node  table->process 

The  set  of  processes  located  in  th  node  "referenced"  by  the  node 
tab’e,  and  for  which  the  node  in  which  the  nodo  table  resides  needs 
information. 
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node  table/dbo/nessage_group/operator_connection->process 

TEs  set  of  prooesses  in  a particular  state.  If  the  owner  is  a 
node  table  which  "references"  the  node  in  whioh  it  is  located,  then 
the  process  is  in  the  ready  or  running  state.  If  the  owner  is  a 
database  object,  the  the  prooess  is  waiting  for  access  to  that 
database  object.  If  the  owner  is  a message  group  or  operator  con- 
nection, then  the  process  is  waiting  for  text  in  that  sassage  group 
or  over  that  operator  connection. 

entity  aeaber  roles: 
node->node_node_table 


An  ordered  blocked  process  list  used  to  detect  deadlock. 

entity  attributes: 
obpl.resjMuae 

The  naae  of  the  reaouroe  for  which  the  most  recently  inserted  process 
into  the  OBPL  is  waiting. 

obpl . res_nodc  naae 

The  naae  or  the  node  in  whioh  the  above  Mentioned  resource  resides, 
obpl .rea_type 

The  type  (database  object,  message  in  a message  group,  or  message 
over  an  operator  connection)  of  the  above  mentioned  resource. 

obpl . mag  numb 

If  the  above  mentioned  resouroe  is  a message  in  a message  group,  then 
this  attribute  contains  the  number  of  the  message  (within  the  message 
group)  that  is  being  waitied  for. 

entity  owner  roles: 

OBPL->OBPL_process_entry 

The  set  of  prooesses  and  operators  that  have  been  inserted  into  the 
OBPL. 

entity  aeaber  roles: 

0BPLu.pas8-  >OBP  L 

operator->OBPL 

OBPL  PASS 

Tnis  is  used  to  pass  an  OBPL  from  one  node  to  another,  where  it  can  be 
further  expanded. 

entity  attributes: 

obpl  Dase.des  node_name 

Tne  naae  or  the  node  to  which  the  OBPL  is  being  sent  for  further 
expansion. 

entity  owner  roles: 

OBPLpass->OBPL 

Tnis  is  a one-to-one  relationship  with  the  member  being  the  OBPL 
that  is  being  passed  from  one  node  to  another. 

entity  member  roles: 
systera->OBPL_pass 

OBPL_PROCESS_ENTRY 

This  represents  a ppocess  that  has  been  inserted  into  an  OBPL. 

entity  attributes: 

proc„entry . node„name 

The  name  of  the  node  in  which  the  process  that  has  been  entered  into 
the  OBPL  resides. 
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proqentry . proces s _naae 

Tne  name  of  the  process  that  has  been  entered  into  the  OBPL. 

entity  owner  roles:  (none) 

entity  aeaber  roles: 

0BPL->0BPL_proces8_entry 

OPERATOR 

This  entity  represents  a person  that  has  been  declared  as  an  operator  at  a 
given  node. 

entity  attributes 
operator. naee 

The  unique  naae  for  the  operator  in  the  node  at  which  he/she  is  lo- 
cated. 

entity  owner  roles: 
operator->OBPL 

The  set  of  OBPL’s  that  require  state  information  about  the  operator 
before  they  can  be  further  expanded. 

operator->operator_oonnect ion 

The  set  of  operator  connections  over  whioh  the  operator  eay 
cesaur.ieate  with  processes. 

entity  aeaber  roles: 
node_table->operator 

OPERATOR  CORRECTION 

An  entity  via  whioh  aessages  are  sent  from  an  operator  to  a process. 

entity  attributes: 
op_.oon.naae 

The  network  unique  naae  for  the  operator  connection 
op  con . nuaber_qd 

The  nuaber  of  aessages  that  have  be6n  sent  by  the  operator  but  have 
not  yet  been  received  by  the  process  over  this  operator  connection. 

entity  owner  roles: 

operator_conneotion->process 

The  set  of  processes  waiting  for  text  over  the  operator  connection. 
The  nature  of  exclusive  assignment  of  an  operator  connection  to  a 
process  precludes  more  than  one  process  to  actually  be  waiting  for 
text. 

( see  node_table/d  bo/me  ssaga_g  roup/operato reconnect ion- >process ) 

entity  aeaber  roles: 

opera tor->operator_connect ion 

proceas->operator_conneotion 

systea->operatcr_conneot ion 

PROCESS  (PROCESS  COMMITMENT  UNIT) 

This  represents  a process  which  is  executing  within  a process  cooaitaent 
unit  (the  period  between  prooess  commitment  points).  Processes  are  unique, 
as  are  process  commitment  units,  therefore  the  model  treats  them  as  one 
entity. 

entity  attributes: 
process. access_type 

If  the  process  is  waiting  for  access  to  a database  object,  this  at- 
tribute denotes  the  type  ("shared"  or  "exclusive")  of  access  desired. 
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process. name 

The  unique  name  of  the  process  within  the  node  in  which  it  resides. 


entity  owner  roles: 

process->dsbetsse_object  . ...  . ^ _ 

The  set  of  database  objects  currently  exclusively  assigned  to  the 


froeess  for  read/write  purposes.  If  a database  object  is  not 
nserted  in  such  a set,  and  its 

database  objeet»>database_objeot_sbared_ assignaent  set  is  eapty,  then 
it  is  available  for  exclusive  assignaent. 


proo*aa->dat*bas«_object  shared  asaignatent 

The  set  of  database_oT3ject_8hared_asaignment 
database  objects  assigned  to  a process  on  a 


entities  representing 


process 


shared  (read  only)  basis. 


proeess->aesaage_group ( rece ive ) 

The  set  of  aessage  groups  vhioh 
(The  process  can  reoeive  neaaag 


have  been  aooepted  by  the  process, 
aessages  in  these  aessage  groups.) 


proce8s->aeasage_group(send) 

The  set  of  aessage  groups  which  have  been  Initiated  by  the  process. 
(The  process  can  send  aessages  in  these  aessage  groups.) 


proceas->operator_conneotion 

The  set  of  operator  connections  over  whioh  the  prooess  oan  receive 
aessages  froa  operators. 


entity  aeaber  roles: 
node_table->process 


rode_table/dbo/nesaage_jgroup/operator_oonneotion->prooe88 


RESOURCE  GRANT 

The  internodal  message  granting  a prooess  aooess  to  a database  object  lo- 
cated at  a different  node. 


entity  attributes: 
res  srant . proc_naaa 

The  name  of  the  process  that  ia  being  given  access  to  a database  ob- 
ject. 


ressrant . proc_nodde_name 
The  name  of  the  node  i 


e name  of  the  node  in  which  the  above  mentioned  process  resides. 


res  grant . res  name 

The  name  o?  the  database  object  whioh  the  above  mentioned  process  is 
gainlg  access  to. 


res  grant . resjnode_name 

The  name  or  the  node  in  which  the  above  mentioned  database  object 
resides. 


entity  owner  roles:  (none) 


entity  member  roles: 

system->resour<,'j_grant 


RESOURCE_RELEASE  

rne  internodai  message  stating  that  a given  database  uujsut  «»ae  Keen  re- 
leased by  a specified  process. 


entity  attributes: 

res  rel .dest_dbo_name 

The  name  of  the  database  object  being  released. 


res  rel.dest_node_name 

The  name  of  the  node  in  which  the  released  database  object  resides. 


i 
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res  rel . relwpnodq_naae 

The  naae  of  the  node  in  which  the  process  releasing  the  database  ob- 
ject resides. 

res  rel.reiLproe  naae 

The  naae  of  the  process  releasing  the  database  objeot. 

entity  owner  roles:  (none) 

entity  aeaber  roles: 

syatea->resource_release 

RESOURCE_REQUEST 

The  internodal  message  in  whioh  a prooess  requests  access  to  a database 
object  located  at  a different  node. 


entity  attributes: 
res  req . aooesstype 

The  type  of access  ("shared"  or  "exclusive")  that  has  been  requested, 
res  req . dest-dbcunaoe 

The  naae  of  the  database  object  to  which  access  has  been  requested. 


res  req.dest.node_naae 

The  name  of  tho  node  in  which  ths  dssirsd  database  objeot  resides. 


res  req . reqjnode name 

The  naae  of  the  node  in  whioh  the  requesting  process  resides, 
res  req . req  prop  naae 

The  naae  of  the  prooess  requesting  acoess  to  the  above  mentioned 
database  object. 

entity  owner  roles:  (none) 

entity  aeaber  roles: 

systea->resource_request 


SYSTEM 

The  coaputer  network. 

entity  attributes: 

systea. last_contjB3g 

The  number  oflnternodal  control  messages  that  have  been  sent  in  the 
network. 

entity  owner  roles: 

system->aessage_group 

The  set  of  message  groups  that  have  been  initiated  throughout  the 
network. 

systeB->aessage_text/OBPL/pass/resource_grant/resource_release/ 

reaource_request 

The  set  of  control  messages  that  have  been  sent,  but  have  not  yet 
been  received  by  the  destination  node.  The  type  of  control  message 
represented  is  uniquely  determined  by  the  entity  tyoe  of  the  member. 

aystem->node 

The  set  of  nodes  in  the  network. 
system->operator_connection 

The  set  of  operator  connections  that  have  been  declared  within  the 
network. 

entity  member  roles:  (none) 
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The  AOT  Deadlock  Detection  Model  cons late  of  seven  PL/I  procedures,  each 
of  which  contains  multiple  entries.  A deearl pt ion  of  the  Deadlock  Detection 
Model  user  visible  functions  begins  on  the  next  page.  Included  in  tho  de- 
scription of  a fjnotion  1#  the  name  of  the  procedure  in  vhioh  that  function 
appears.  The  seven  PL/X  procedures  follow  the  function  descriptions,  and 
these  procedures  are  followed  by  the  two  PL/I  include  files  which  are  used  by 
the  various  procedures.  Pile  DDKjssrvjroutines  contains  dsolarstlons  of 
Deadlook  Detection  Model  functions  which  srs  called  by  other  functions  within 
the  Model,  and  file  ADT_priaitives  oontaine  declarations  of  thr  AD?  system 
functions. 

The  following  is  an  index  to  the  PL/I  procedures  and  inolude  files. 


ADT_primitivea 

DD»* 

DDM_aerr_rou tines 

OBPL 
or  CON 
PCT^CM 
PEL 
REQ 
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USER  VISIBLE  FUNCTIONS 
ACT  Deadlock  Detection  Mechanism 


User  Visible  Functions 


&eeeptag(  p_ag„name , p_acoeptjnods-flame , pace e p t_p r oo_name ) 

Declares  prooess  "p  aocept_proo_naae"  located  in  node 
"p_aocept_node_name"  as  the  only  prooess  that  oan  recef/e  messages  in  the 
message  grcup  specified  by  "p_pgjname".  acceptmg  is  located  within  procedure 


cdbo( pnodejname , p dbo_jnaae) 

"creates"  a database  objeot  at  the  node  specified  by  "onode  name".  The 
database  object  has  a "local"  name  specif ieo  by  "p_dbo_name".  odoo  is  located 
within  procedure  DDM. 

onode  ( p_jnode_naae ) 

"Creates"  a node  with  the  name  specified  by  "p_node_name".  onode  is  lo- 
cated within  procedure  DIM. 


copcon(p_con_name,  p_con_node_name . p - p natie , p_prooess_name) 

"Creates"  an  operator  connection  between  operator  "p_op_name" 


and  process 


rocess  name" , both  located  in  node  "p_eon_nbde_name"'.'  -W  operator'  eon- 
' ‘ ‘fled 


ncction  will  have  the  global  nane  sped 
cated  within  procedure  OP_GON. 


by  "p_con_name".  copcon  is  lo- 


cproc(p_node_name,  p_prccess  name) 

"Creates"  a prooess  with  the  name  specified  by  "p_procesa  name"  and  lo- 
cated in  the  node  specified  by  "p_node_name" . oproc  is  located  within  proce- 
dure DDM. 


dclop(  p_op_node_name , p._cperator_name) 

•Decl&rea"  that  an  operator  with  name  "p_operator  name"  exists  at  the 
node  with  name  "p_op_node_nsme" . dolop  is  located  within  procedure  DDM. 

inltag(p «g_name,  p_init_node_namef  p_init_proo  name,  p_accept  node  name) 

Declares  orccess  "p_init_jproc_name"  located  in  node  "p_init_node  name"  as 
the  only  prooess  that  een  send  messages  in  the  message  group  specified  by 
"D_mg_name".  All  messages  in  the  message  group  will  be  sent  to  a process  in 
the  node  specified  by  "p_aocept_node_naH8".  initmg  is  located  uitnin  proce- 
dure MSG. 

opmsg ( p_con  naae ) 

"Sends"  a message  from  the  operator  to  the  prooess  in  operator  connection 
"p_con_cfnie".  opmsg  is  located  within  procedure  0P_C0N. 

opstat ( p_op_node_namt.  , p_op_ram&,  p_state,  p_con_naae) 

States  that  operator  "p  op  name"  at  node  "p_op_node__name"  is  either 
"active"  or  "waiting"  (specified  by  "p_state").  If  the  operator  is  waiting, 
it  would  like  to  receive  a message  from  the  process  in  operator  connection 
"p_con_name".  opstat  is  located  within  procedure  0P_C0N. 

r cvcm  ( p_cont_jasg_numb ) 

Causes  the  control  message  with  number  specified  by  "p_cont_asB_numb'!  to 
be  received  by  the  appropriate  node  and  the  required  action  then  takes  place, 
revem  is  located  ,'itnin  procedure  RCV_CM. 

rcvmsg(  p_mg_name ) 

Causes  a message  to  be  "received"  in  measage  group  "p_mg_rame".  If  no 
messages  are  queued,  then  the  receiving  process  is  blocked,  rcvmag  is  located 
within  procedure  MSG. 

r cvcpmsg ( p_con_  name ) 

Causes  a message  to  be  "received"  by  the  prooess  in  operator  connection 
"p_con_name".  If  no  messages  are  queued,  then  the  process  is  blocked  and  we 
request  the  status  of  the  operator  involved  with  this  operator  connection, 
revopasa  is  located  within  procedure  0P..C0N. 
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r ldbo ( p_proc  nodejnaae , p _process_name,  p_dbo_node_nsae , p_dbo  name) 

Causes  the  database  object  "sdbqjnaie"  located  in  the  node  speoified  by 
”p_dbo_nodejnaae"  to  be  released  by  prooess  "pjprocesa  name"  in  node 
"p  oroo  noda_naae" . If  additional  prooessee  are  queues  for  the  database  ob* 
Jeet,  they  aay  be  reaoved  fro*  the  queue  In  aoecrdanoe  with  the  rules  for 
resouroe  allocation,  rldbo  is  located  within  procedure  REL. 


rqdbo  ( p_aooeas_type , . pjproc_node„nan’  os , p_j>rooeas_naas , p_d bo_node_naae , 
p_(lhn_naas  > 

Handles  a request  by  process  "p_jprocesawnaae"  (located  at  node 
"p_proc_noda_jnaae" ) for  aooess  ("shared"  or  "exclusive"  as  specified  by 
"P_aocess_type")  to  the  database  object  specified  by  "p_dbo_naae"  and  located 
in  the  node  specified  by  "p_dbo_node_ria*e" . rqdbo  is  located  within  procedure 
HEQ. 


sendnsg(  p_jng_naet) 

"Sends"a  message  in  the  message  group  speoified  by  "p_j«g_nane" . sendasg 
is  located  within  procedure  MSG. 


sysgen 

"Creates"  ( initial izes ) 
DDM.  Internally  it  also  has 


the  system,  sysgen  is  located  within  procedure 

the  name  "oays". 
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Procedure  DDM 


d6m: 


procedure; 

/*  This  procedure  is  a collection  of  subroutines  which  either 

» _ ' J _ J A.  _ J ^ *1  A.  _ A J 'I I ^ J _ A _ . 1.  f _ « i LI _ „ 


creates  entities  needed  to  model  the  deadlock  detection  algorithm  proposed 

;ne  model . 


by  Barry  go 
The  follow! 


jerforas  services  for  other  routines  used  in  tt 


The  following  au 


ing  user  visible  funotlons  are  included: 
CREATE  DATABASE  OBJECT 
CREATE  NODE 
CREATE  PROCESS 
CREATE  SYSTEM 
DECLARE  OPERATOR 


routines  are  included: 
DATABASE  OBJECT 

DATABASE  OBJECT  SHARED  ASSIGNMENT 
CONTROL  MESSAGE 
NODE  TABLE 
OBPL 

DECLARE  OBPL  CONTROL  MESSAGE 
DECLARE  PROCESS 
DECLARE  PROCESS  2NTRY 
DECLARE  REMOTE  RESOURCE  GRANT 
FIND  ENTITY  LOCATION 
INITIATE  OBPL  •/ 


DECLARE 

DECLARE 

DECLARE 

DECLARE 
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Procedure  DDM 


i! 


r 

I 


del  oont_msg_nufflb 

del  d bo ref 

del  eoa 

del  exp.obpl 

del  aeaaaiMurruob 

del  agref 

del  node ref 

del  no _aore_nodes 

del  obpl_paaaref 

del  obplref 

del  opref 

del  p_attr_claaa_nane 

del  p_eont_«Bg_numb 

del  P_dbo_naae 

del  P_dbo_node_name 

del  p_dcl_cont_aag_nunb 

del  p_dcl_dbo  name 

del  p_dcl_entTty  _c la  a s„name 

del  p_dcl_node_ta*>l_rvaoe 

del  p_dol _j>roe_name 

del  P_dcl  ref 

del  p_deat  node_na«e 

del  p_entity_name 

del  p_entity_ref 

del  p_node_naae 

del  p_obplref 

del  p_operator_name 

del  P_op_node  name 

del  p_ownerref 

dol  p_prooeaa  name 

dol  p_proo_noide_naae 

del  p_rea_naae 

del  p_rea_node_nane 

del  p_rea_type 

del  proo_entryref 

del  procref 

del  proc_termr  jf 

del  p_aend  _node _name 

del  p_aet_claaa_naae 

del  rea_grant_ref 

del  sec_node_naae 

del  aee  noderef 

del  tableref 

del  tea>p_naae 

del  temp_ref 

del  write  liat_ 

tinclude  ADT_primitives: 


in  is 


fixed  bin: 
fixed  bin?17); 
bit(l): 

entry? fixed  bin(17),  char(12)); 
fixed  bin; 
fixed  bin? 
fixed  bin? 
bittl);  , % 
fixed  bin?',7 
fixed  bin? 17 
fixed  bin? 17) 
ehar(44): 
fixed  bin; 
char?*): 
char? 12); 
fixed  bln; 
char? 12); 
ohar?20): 
char? 12) 
chart  12) 
fixed  bin 
ehar?  1 2 ) ; 
char?12); 
fixed  bin(17); 
chart*): 
fixod  bint  17); 
char?*); 
char?*); 
fixed  bin( 17); 
char?*): 
char? 12' 
char? 12, 
char? 12, 
ohar(7) ; 
fixed  bin 
fixed  bin 
fixed  bin 
char? 12); 
ehar?20); 
fixed  bin 
chart  12); 


1 17) : 


(17): 


fixed  bin? 17); 

fixed  bin? 17); 

chart  12); 

fixed  bint  17); 

entry  options(variable): 
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/»  CREATE  DATABASE  OBJECT  , 5/21/76  •✓ 

create  database  object : cdbo:  entry(p_node_name,  p_dbo_name) : 
if  fin<J_entity„_Toct  noderef,  "sys->node" , SYS_REF,  p_node_naae , "node. name") 
then  do: 

call  write_list_( "Invalid  node  name.  ",  p_node_naE?e, 

"does  not  exist."): 

return; 

end: 

eos  = find  entityJLoc( tableref,  "node->node_table" , noderef,  p_node_name, 
"node_t«ble . name" ) ; 

if  find_entity_loc(dboref,  "node->dbo",  tableref,  p_dbo_name,  "dbo.name") 
then  do: 

call  write_list_(  "Duplicate  database  object  name"); 

return; 

end: 

call  del_dbotdboref,  p_dbo_name): 
call  insert  (dboref,  "node->dbo".  "first",  tableref); 
call  *rit«t_list_("Datab33e  object  ",  p_doo_name,  " created  in  node  ", 
,_node_naae) : 


return; 


:._node_ 


/•  CREATE  MODE  5/19/76  •/ 

create_node:  cnode:  entry(p  node.name); 
if  owner  (SYS_RBF,  "sys->no3e") 
then  do: 

call  write_list_("Illegal  request,  system  has  not  been  created."); 

return: 

end; 

call  find  firat_( noderef,  "aya->node",  SYS_REF,  nojnore_nodes) ; 
do  while  T no  more  nodes): 

if  ex  racT  (noderef , "node. name")  = p_node_name 
then  do; 

call  write_list_( "Duplicate  node  name"); 
return; 

call  find_next_( noderef , "sys->node",  no_more_jiodes); 
end; 

call  cref*te_entity_(noderef , "node"); 

caU  ereate_attribute  (noderef,  "node. name",  "field",  12.  p_node_name) ; 

« .'1  create_relationship_( noderef , "sys->node",  "member"); 

' v.  i . nset*t_( noderef , "sys->node",  "first",  SYS  REF): 

call  ^.-eate  relationship_(noderef , "node->node_Table",  "owner"): 

cell  dcl_nodetable( tableref,  p_node_name) ; 

call  insert  (tableref,  "node->node_table" , "first",  noderef); 

r*  We  will  now  make  this  new  node  "aware"  of  the  existence  of  all 
other  nodes,  and  make  all  other  nodes  "awsre"  of  this  new  node.  */ 
sec  noderef  « noderef; 

calT  find  next_(aec_noderef,  "sys->node",  no_more_nodes) ; 
do  while  T no_jmore__nodes) ; 

/•  First  create  a table  entity  for  the  new  node  to  be  used  by 
another  node.  */ 

call  dcl_node  table( tableref , p_node_name) ; 

call  insert. (Tableref , "node->node_table".  "first",  sec.noderef) ; 

/*  Now  create  a table  entity  for  an  existing  node  to  be  used  by  the 
new  node.  */ 

sec  node.name  = extract  (sec_.noderef , "node. name ") ; 

calT  de)._node_table(  tableref , sec.node  name) ; 

call  insert_( tableref . "node->node  table",  "first",  noderef): 

call  find_next_(sec_noderef , "sys-Tnode",  no_more_nodes) ; 

end- 

call  write_list_("Node  created:  ",  p„node_name) : 
return-  / 
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/•  CREATE  PROCESS  , 5/21/7C  V 

create .process?  eoroc:  entry(p_node_naae,  p oroceaa_na«e) ; 

If  flnd_entity_loe(noderef , "sys->node",  SxS_hEF,  p_node_nawe,  "node. name") 
then  do: 

call  write  list_( "Invalid  node  naae.  ",  p_node_name, 

*does  not  exist") ; 

return: 

end: 

eoa  * find_entity_loc( tableref , "node->node_table" , noderef,  r node_name, 

A "node_.table.name"); 

If  find_entity_loe(prooref , "node->prooeaa" , tableref,  p_prooe83_name, 
"process. name") 
then  do: 

call  write_list_( "Duplicate  process  name"): 

return: 

end: 

/*  If  an  operator  with  the  same  name  has  been  declared  at  the  node. 

print  an  error  message  and  return  •/ 
if  find_entity_loc(opref.  "node->operator" , tableref,  p_prooecs_name , 
"operator. naae") 
then  do: 

call  write  list_(p_prooess_jiame,  "has  been  previously  declared", 
"as  an  operator  at  node",  pjnode_naoe) ; 

return: 

end; 

call  dcl_process(prooref,  p _process_name) : 

call  insert* procref,  "node->process" , "first",  tableref): 


4.  uv a.  i/t  wucov  pa  vvii  ot  | p wi  vvcoj ,t  name i • 

call  insertfprocref,  "node->process" , "first",  tableref); 
call  insert  (prooref,  "node/dDo/mg«>prooess",  "first",  tableref); 
call  write_liat„("Process",  p_process_name , "created  in  node",  p 


return; 


.nod<L_naae) ; 


/•  CREATE  SYSTEM  5/18/76  •/ 

create_syst:  cays:  sysgen:  entry; 
if  SYS  ReF  '=0 
then  do: 

call  write_list_( "System  already  created"); 

return; 

end; 

call  ereate_entity_(SYS  REF,  "system"); 

call  create_attribute  (SYS  REF,  "system. laat„cont_jBsg",  "field",  10,  0); 

call  create.  j'jlationsliipTSYSLREF , "sys->node",  "owner"); 

call  creaie_relationsh.lp_(SYS_REF,  "sys->asg_grp" , "owner"): 

call  ereate_relationship  (SYS_REF,  "sys->oontrol  message",  "owner"); 

call  ereate_relationahip_(SYS_REF,  "sys->message",  "owner"); 

call  create  relationship_(SYS_REF,  "sys->op_con" , "owner"); 

call  write_list_( "System  created"); 

return: 


/*  DCL  DBO 

dcl__dbo:  entry (p_dcl_ref , p_dcl  dbo_name) 

/*  This  procedure  creates  an  entityy  for  a database  object  with  name  specified 
by  "p_dcl_dbo_name"  and  creates  the  necessary  relationships.  A reference 
to  the  entity  is  returned  via  "p  dcl_ref".  »/ 
call  create_.entlty_(p_dcl_ref , "dbo""): 

call  create_attribute  (pdal  ref,  "dbo.name  . "field".  12,  p dcl_dbo  name); 


5/27/76  •/ 


_ r_  dbo.name  . "field",  12,  p dcl_dbo  name): 

call  create_relationsnip_(p_acl_ref , "process->dbo" , "member1";:  ~ 

call  create„relationship_(p_dcl..ref , "node->dbo" , "member"); 
call  create_reletlonship  (p_dci_ref , "dbo->dbo  sh  asmt".  "owner"): 
call  create_relaMonship_(p_dcl_ref , "node/dbo7mg->processr' , "owner"); 
return- 
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n Da  DBO  SH  ASMT  5/27/76  •/ 

del  dbo_sh_asmt : entry (p_dcX_ref) ; 

/*  This  procedure  creates  an  entity  for  a database  object  shared  assignment 
and  returns  a pointer  to  it  via  "p  dcl_ref"  */ 
call  create_entity_(p_dcljref,  "dbo_sh_asat") ; 

call  crrate_relationanip_Tp_.dclwref , "proeesa->dbo„sh_asmt",  "member") ; 
call  create_relationship_(p_dcl_ref , "dbo->dbo_sh_asmt",  "member1*) : 
return; 


/•  Da  CONTROL  MESSAGE  5/27/76  •/ 

dcl_control_message : entry(p_del_ref , p_dcl_entity_clas3_name, 
p_dol_cont  msg^numb) ; 

/*  This  procedure  will  establish  an  OBPL,  a remote  resource  request  or  a 
remote  resource  release  as  a control  message.  It  will  generate  a control 
message  numbe-  (which  becomes  an  attribute  of  the  entity  specified  by 
"P_dcX_ref" ) and  change  the  "system  entity  so  that  it  is  aware  of  the 
new  control  message  number.  This  control  message  number  is  returned  via 
"p_dcl cont_ msgnumb"  •/ 

p_deX_cont_mstt  numb  * extract  (SYSJREF,  "system. last_cont_msg")  <■  1; 
call  alter_(SYS_REF,  "system.  Tast_oont  mag",  p_dcl_oont msgnumb) : 
call  create_order  (p_del_ref.  p_dcl  entity  class_name,  "control_jnessage" ) ; 
call  create_relatlonahip_(p  del  ref;  "sys->cortrol_message",  "member"): 
call  create_attribute_(p_dcT  ref,  "control_jaessage. number",  "field",  10, 
p_dcl_oont_msg_numb) ; 

return; 


/•  Da  NODE  TABLE  5/27/76  •/ 

del  node_t«ble : entry(p_dcl_ref,  p_dclwnode_tabl_name) ; 

/•  This  procedure  will  create  an  entity  for  a node  table  and  creates  the 
necessary  relationships.  The  entity  is  also  given  the  name  specified  by 
■p  dcl_node_tabl  name" . A pointer  to  the  new  entity  is  returned  via 
*P_dcl_ref".  •/ 

call  create_entity_(p_dcl  ref,  "node_table"); 

call  oreate_attribute  (p  ael_ref,  "node_table.name",  "field",  12, 
P_dclwnode_tabT name) ; 

call  ereate_relationship  Tp_dcl_ref , "node->node_table",  "member"); 
call  create_relationship_(p_dc]wref , "node->operator",  "owner"); 
call  create_relationship_(p_dcl_ref , "node->process" , "owner"); 
call  create_relationship_(p_dcl^_r6f , "node->dbo";  "owner"): 
call  ereate_relationship_(p_dcl_ref , "node/dbo/mg->process",  "owner"); 
call  create_relationship_vp_dcl_ref,  "init_node->message",  "owner"): 
call  create_relationship_(p_del_ref , "accept_node->message",  "owner"); 
return: 


i 
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/•  DECLARE  OBPL  6/24/76  •/ 

del  obpl;  entry (p_obpl ref,  p_res_node_na«e , p_res__naoe , p_res_type) : 

/*  This  procedure  will  create  an  entity  for  an  OBPL.  Included  In  this 
entity  will  be  at tribute  fields  whioh  give  the  mum,  type  snd  node  naae 
for  the  resource  that  the  most  recently  Inserted  prooess  into  this  OWL 
is  waiting  for.  The  location  of  the  ObPL  entity  Is  returned  via  the 
parameter  "p  obplref"  */ 
call  create_entTty_(p obplref.  "obpl"); 

call  create_relatlonsnip(p_obplref,  "obpl  _pass->obpl" , "member"); 
call  create_relationship_(p_obplref , "operator~>obpl",  "member"); 
call  create_relationship_f p_obplref , "obpl->proo  entry",  "owner"); 
call  create_attribute_ (p  -bplref,  "obpl.res_jiame",  "field",  12,  p_res  name); 
call  create_attribute_(p_obplref , "obpl.res_type",  "field",  7,  p_res_type); 
call  create_attribute_(p_obplref , "obpl.res_node_name",  "field",  12, 
p_res_nocle_name) : 

/*  Create  an  attribute  (to  be  altered  only  when  the  resource  is  a message) 
to  Indicate  the  message  number  within  a message  group  that  is  being 
waited  for  */ 

call  create_attribute_(p_obplref,  "obpl.msg_numb",  "field",  4,  "0"); 
return: 


/•  DECLARE  OBPL  CONTROL  MESSAGE  6/25/76  */ 

del  obpl_oont  mag:  entry (p_obplref , p_dest _node_naae,  p_send_node_narae); 
/•  This  procedure  creates  a control  message  used  to  pass  the  OBPL  pointed 
to  by  "p_obplref"  from  the  node  specified  by  " r>  a en d_node_name " the  the 
node  specified  by  "p  dest_node_name"  */ 
call  create_entity_(obbI  oassref,  "obpl  pass"); 

call  create  attribute^ oopl_passref,  "obpljpass.dest_node_name",  "field", 
12,  p_dest_node_name) ; 

call  create  relationship_Jobpl_passref,  "obplpass->obpl",  "owner"); 

/*  Insert  the  OBPL  into  this  control  message  */ 

call  insert_(p_obplref,  "obpl_pass->obpl",  "first",  obpl  oassref); 

/*  Declare  the  "obpl^jjass"  as  a control  message  •/ 
call  decontrol  message(obpl_passref,  "obplupass",  eon'-  magnumb): 
call  insert  (obpTpassref,  "ays->control  message" , "last  SYS  REf); 
call  write_list  ("Control  message  number",  cont_jJsg_numb,  "cent  from", 
p send_node_name,  "to",  p dest_node  name); 
call  write_Xist_T"  representing  an  OBPL"); 

return; 
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DECLARE  OPERATOR  7/13/76  */ 

dclop:  ent ry ( p_©p_node_n ame , p_operator  name) ; 

/*  This  procedure  will  create  an  entity  7or  an  operator  with  name  specified 
by  "P_operator  name"  and  located  at  the  node  specified  by 
P_op_node_name"  */ 

/*  If  the  node  specified  by  "o_pp_node_naae"  does  not  exist,  print  an 
error  message  and  return  */ 

if  find_entitvj.oo(noderef,  "ays->node",  SYS_REF,  p_op_node_name, 

"node. name" ) 
then  do: 

call  write_list_("Xnmalid  node  name:",  p_op  node  name, 

^does  not  exist"):  ’ 

return; 

....  ..  ®d<>; 


/'  It  p„operator_name"  was  previously  declared  as  an  operator,  print  an 
jrror  message  and  return  •/ 

if  f ind_entity_loc( opref . "node->operator" , tableref,  p operator  name, 
"operator. name")  ~ 

then  do: 

call  write_list_(p  operator_name,  "has  been  previously", 

"declared  as  an  operator  at  node”,  p op  node  name); 

return: 

end; 

/•  If  "p_operator_jname"  was  previously  declared  as  a process,  print  an 
jrror  message  and  return  •/ 

if  f ind_entity_loc( procref , "node->process",  tableref,  p_operator_name, 


nnd_entity_locv procrer,  "node->process",  tableref,  p_operator_name, 
"process. name") 
then  do: 

eall  write  list_( p_operator_name , "has  been  previously  declared", 
"as  a process  at  node",  p_op_node_name) ; 

return; 

end; 


/*  Create  an  entity  for  the  operator  and  declare  the  necessary 
relationships  and  attributes  */ 
call  ereat«t_entltv  (opref,  "operator"); 

call  ereate_attribute  (opref,  "operator. name",  "field",  12,  p_operator_name) : 
call  creat*_relationship  (opref,  "operator->op_con",  "owner"); 
call  create_relationship  (opref , "operator->obpl",  "owner"); 

real  1 i An mVtl  n i nnna^  \ . 


TTr-)  f wyv.  mvwi-fwwp*  . WWUOJ  / * 

call  create_relationship_(opref,  "node->operator",  "member"); 
call  insert  (opref,  *node->operator" , "first",  tableref); 
call  write  list_(poperator_name,  "has  been  declared  as  an  op< 
"at  node",  p_op_node_name) ; 

return; 


operator" , 
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/•  DCL  PROCESS  5/27/76  •/ 

dclproceaa:  entry (p_dcl_ref , p_dcl_procnaae) : 

/*  This  procedure  will  create  an  entity  for  a process,  give  it  the  name 
specified  by  "pdclproc_name"  and  create  the  necessary  relationships 
call  create_entity_(p_dcl_ref,  "process*); 

.name",  "field*,  12, 


call 


p~dC!l_proc_naae) ; 

create3ttribute^(p_dcl  ref,  "process . accesa_type" , 
create_relationanip_ip_aol_«'ef , "node->process" , "» 


call 

call  _ _ 
oall  creat«_relationship_ 
oall  create_relationship_ 
call  create_relation8hlp_ 
call  create_relationship_ 
call  create_relationship_ 
call  create_relationship_ 
return* 


"field" 

); 


10,  *")! 

) j 

P~dcLJ*«fi  "nod#/dbo/mt->proceas",  "■ember"); 
P-.dol_.ref,  "process->dbo* , "owner"); 
p_dcl_ref , *prooeaa»>dbo_sh  aaat” , "owner"); 
pdc^ref,  "prooese~>op_oon\  "owner"); 
p_do!L.ref , "sendjproo->meaaage",  "owner"); 
P_.dcL.ref,  "rcv_proc->mesaage" , "ovrur") ; 


/•  DECLARE  PROCESS  ENTRY  6/25/76  •/ 

del  oroc_entry!  entry<p_obplref,  p. j>roo_node_na«e , pjprooeaa  name ) : 

/•  This  procedure  will  create  an  entity  for  a process  entry  In  an  OBPL. 
The  entity  will  be  Inserted  into  the  OBPL  pointed  to  by  "oobplref* 
and  its  process  and  location  of  the  process  will  be  specified  by 
"p_process_naae"  and  "p_proc_node_name",  respectively  •/ 
call  create_entitv  (procintryref,  "proc_entrv"); 

call  create_relationship_(proc  entryref,  "obpl->proc_entry" , "member"); 
call  create  at tribu ted procentryref,  *proct_entry.process_naiie*,  "field", 
12,  p _proceaa_name) ; 

call  oreate  atlribute_(proo_entryref,  "proc_entry.node_pame",  "field", 

1?,  p_proo  node  name) ; 

call  insert_(proc_enTryref,  "obpl->proc_entry" , "first",  p_obplref); 
return; 


/•  DECLARE  REMOTE  RESOURCE  GRANT  6/17/76  •/ 

dcl_renL_res__grant:  sntry(p_dbo_node_nam*.  p_dbo_naae,  p_proc_.node_name , 
p_procesa  name , p_cont_jBaa  numb) ; 

/*  Thia  procedure  will  create  an  entity  for  a remote  resouroe  allocation  and 
then  declare  it  as  a oontrol  message.  The  resource  represented  by 
"p  dbo  name"  at  the  node  represented  by  "p_dbo_node_juame*  will  be 
allocated  to  the  process  represented  by  "p_process_name"  at  the  node 
represented  by  "p_proc_node  name".  The  control  message  number  will  be 
returned  via  the  parameter  "p  oont_jnsg_numb".  •/ 
call  ci'eate_entity_(rea_grant_ref,  "res_grant") : 
call  create _attribute_(rea  *rant_ref , "res_grant.res_node_name", 

"Yield",  12,  p_dEo_node_name) ; 
call  create  attributed reserantref,  "res__grant.res_name", 

"Yield",  12,  p_dho_name); 

call  create attributed rea_grant  ref,  "res_grant.proe_node_name" , 

"Yield",  12,  p_proc_noae_naae) ; 
call  create  attributed rea__grant_ref,  "res_grant.proc_name", 

"Yield",  12,  p _procesa_name) ; 
call  dcl_control_messageTres_jgrant_ref , "res_grant" , 
p_cont_msg_numb) ; 

call  insert_(rea_grant_ref,  "sys->control_neaaage" , "last",  SYS  REF); 
return; 


ft 
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FIND  ENTITY  LOCATION 


5/19/76 


f ind_entity_loc : entry (p_entity_ref,  p_aet_claaa_name , p ownerref, 

/.  p_entity  name , p_attr_claaa_name)  returnafbitOT); 

' Thia  procedure  determinea  the  databaae  addreaa  of  the  entity  with  name 
"p_entitvname"  (apecified  by  the  attribute  "p^attr_claaa_name")  which 
la  a member  of  the  set  occurrence  (designated  By  the  parameter 
"p_aet„_claaa_name")  owned  by  the  record  occurrence  deaignated  by 

If  the  deaired  named  entity  doea  not  exiat,  a true  value  ("l"b)  ia 
returned  and  "p_entityref"  ia  unchanged.  Otherwiae  a falae  value  ("0"b 
ia  returned  and  "p_entTty_ref"  ia  updated  with  the  databaae  addreaa  of 
the  deaired  entity.  */ 

calj  find_firat_(terap_ref,  p_aet_claaa_name , ~ ownerref.  eoa); 
if  eoa 

then  do; 

temp  name  = extract? temp  ref,  pattr_claas_name) ; 
do  while  ( eoa  A (p  entityjname  * temp_name)); 

9*1 1 findLnext_Ttemp_raf , p_aet_claaa_name,  eoa); 
if  eoa 

then  temp_name  * extraot_(temp_ref , p_attr_claaa_naffie) : 


if  * eoa  then  p_entity_ref  » temp_ref: 
return  (eoa); 


/•  INITIATE  OBPL  6/25/76  •/ 

initiate_obpl:  entry(p_j>roc  node  name,  p_proceaa_name,  p rea  node  name, 

/M  p_jrea_name.  p rea  type): 

' Tnia  procedure  will  initiate  the  creation  and  expanaion  of  an  OBPL.  The 
firat  prooeas  to  be  placed  on  the  liat  ia  apecified  by  "p_proceas_name" 
and  ia  located  in  the  node  apecified  by  "p_proc_node  name  . The  proceaa 
ia  waitir<g  for  the  reaource  apecified  by  "p_rea_nameT  and  located  in 
the  node  apecified  by  "p  rea_node_name".  The  reaource  type  ("dbo"  or 
"meaaage")  ia  apecified  Fy  "p_rea  type".  •/ 

/*  Create  the  OBPL  entity  and  have  iT  lnitializt-i  with  the  reaource  and 
proceaa  information  given  by  the  parametera,  */ 
call  dcl_obpl(obplref , p_rea_node_name , p_rea_'jL4ie , p_rea_type); 
call  dcl_proc_entry ( obplref , p_proc_node_name,  p_proceaa_name) ; 

/*  If  the  prooeaa  ia  waiting  for  a meaaage,  then  we  muat  find  out  the 
meaaage  number  (within  the  mesaage  group)  that  ia  deaired  and  put  t’lia 
information  into  the  OBPL.  In  addition,  if  the  proceaa  and  the  aender 
of  the  meaaage  are  in  different  nodea,  then  we  muat  aend  the  OBPL  to  the 
^ initiated  the  meaaage  group  rather  than  try  to  expand 
the  OBPL  right  away  */ 
if  p_rea_type  = "meaaage" 
then  do; 

/*  Get  the  location  of  the  entity  for  the  meaaage  group  •/ 
eoa  = find  entity_loc(mgref,  "ay8->meaaage",  SY5_REF,  p_res_r,'ama, 
"meaaage. name" ) ; 

/*  Get  the  number  of  the  meaaage  deaired  •/ 
meaaage  numb  = extract_(mgref , "meaaage ,number_qd")  4 1: 
call  alter_(obplref,(>"obpI.mag_numb",  meaaage_numb) : 
if  p_proc,.node_name  = p„r-?a_node_name 
then  do: 

call  do l_obpl„contjnag( obplref , p_res_node_name, 
p_proc_node_name) ; 

return: 

end* 

end: 

/*  Expand  the  OBPL  as  much  as  possible  in  this  node  »/ 
call  exp..  obpl(  obplref , D_res_node  name) : 
return- 
end  DDM- 
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REQ:  procedure; 

/*  This  procedure  oontaina  the  subroutine  vhioh  allows  processes 
to  request  database  objects  for  shared  or  exclusive  use.  The  following 
user  visible  funotion  is  included: 

REQUEST  DATABASE  OBJECT  */ 


del 

del 

del 

del 

del 

dol 

del 

dol 

del 

del 

dol 

del 

del 

del 

del 

del 

del 

del 

{include 

{include 


contjttgjmjab 

dbo_noderef 

dberef 

dbe^tableref 

eos 

exc_ownerref 

nde_proc_ownerref 

p_aoces»_type 

p_dbo _naae 

p_dbqjnode_na»e 

pnoderef 

p_proeees_naiee 

P_pro©  node_naae 

proorer 

ptableref 

res_re<L.ref 

sh asatref 

write_list_ 

DDMserv  rout lnes ; 

ADTlpriaTtives: 


wrTte_list_ 
DDMserv  routir 
ADTlpriaTtives: 


fixed  bin:  . 

fixed  bin  T7): 

fixed  bln  1 1* ): 

fixed  bint  17); 

bit(t):  , v 

fixed  bint  17); 

fixed  bint  17): 

chart*)? 

chart*): 

chart*}: 

fixed  bin(17>; 

chart*); 

chart*); 

fixed  bint  17); 

fixed  bin'  1'  i; 

fixed  bln  17): 

fixed  bint  17): 

entry  optionst variable): 
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Procedure  REQ 


/•  REQUEST  DATABASE  OBJECT  5/26/76  */ 

request_dbo:  rqdbo:  entry ( p_aecoss_type , p_proe_node_name , p_process_name , 


p_dborode_na*e , p_Jbo  name) ; 

/*  Verify  that  tne  node  specified  by  "p_proc_node_name"  exists  */ 
if  fin<l_«ntity_loe(pnoderef,  "tyu  ^node",  SYS_PEF,  p_proc _node_name , 

"node. name") 
then  do; 

call  write  liat_( "Invalid  process  node  name.  ",  p_pro~  .node_name, 
"does  not  exist.")? 

return; 

end: 

/•  Verify  that  the  process  specified  by  "p.jprocess_name"  exists  at  node 
" p_proo  node_name " */ 

eos  = fin<L«ntity_loc(ptableref , "node->node  table".  pnoderef, 
P_procLjnode_naae , "node_table . name" ) : 
if  find_encity_loc(prooref,  "node->proeess" , ptableref,  p_process_name, 
"process. name") 
then  do; 

call  write_liat_J "Invalid  prooess  name",  p oroeess_name , "at  node", 
p_proo_node__naae , "does  not  exist."); 

return: 

end; 

/*  Verify  that  aocgss  type  is  "scared"  or  "exolusivj"  •/ 
if  (p _access_type  * "exclusive")  & (r_aceess_type  » "shared") 
then  do: 

oali  write_liat_(  "Invalid  aocsss  type,  request  not  processed"); 

return; 

end; 

/•  Check  if  the  prooess  is  blooked  •/ 

call  Mnd_ovner_( ndnuproc_ovnerref , "node/dfco/mg->prcoess" , procref); 
if  entity_r,iksa_name_J[ndjLj)roc_ownerref)  s "node_tr.ble" 
then  do: 

call  write  liat_( "Invalid  request,  process51,  o_process_jn*me , 

"at  node",  p_proe_node_name,  "is  not  active.  "): 

return : 
end; 

/*  Check  if  the  prooess  and  resource  are  at  the  same  node.  */ 
if  p _proo._node_name  * p dbo_pode_name 

then  do;  /*  Prooess  and  resource  are  at  the  same  node  •/ 

/•Verify  that  the  database  object  specified  by  "p_dbo_name" 
exists  at  node  "p  dbo_node  name"  */ 
if  find_entity_loc(dboref , "node->dbo",  ptableref,  p_dbo_name, 

"dbo. name") 
then  do: 

call  write_list__(  "Invalid  database  object  name.", 


return; 

end; 


p dbo_name,  "at  node",  p_dbo_r.ode_name, 
"does  not  exist."): 


/•Test  to  see  if  the  dbo  has  already  been  assigned  to  the  process*/ 
if  inserted_(dboref , "process->dbo") 

then  do;  /*check  if  the  process  has_exclusive  controJ 


Check  if  the  process  has  exclusive  control 
of  the  database  object  •/ 


call  find_ owner_(exc_ownerref , "process->dbo" , dboref); 
if  procref  * exc_ownerref 
then  do: 

call  write_list_("Invalid  request.  Process", 
p_process_natne,  "at  node", 
p_proc_node_name,  "already  has", 
"exclusive  control  of",  p_dbo_name, 
"at  node",  p„dbo_node_riame) : 

return: 

end: 

end: 

else  do- 

/•Check  if  the  process  has  shared  access  to  the  dbo  */ 
if  A empty„ intersection Jorocref , "process->dbo  sh  asmt", 
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dboref,  "dbo->dbo_sh_asot") 
then  do : 

call  writO-ist_(  "Invalid  request.  Process", 
p_process  name,  "at  node", 
p_proc_node_name,  "already  has", 
"access  to",  p«.dbo_rams,  "at  node", 
P_d  bo_node_naae ) ? 


return: 

end: 

end: 

/•  Check  if  the  database  object  might  bg  available  for  assignment  •/ 
if  inserted_(dboref,  "proeess->dbow)  I empty_(dboref, 

"node/dbo/ag->proces8* ) 
then  do: 

/•Block  the  process  if  the  database  object  has  been 
assigned  to  another  process  for  exclusive  use  or 
if  other  Droceases  are  currently  queued  for  the 
database  object  •/ 

call  alter_(  procref.  " process. acoess_type", 
p_aecess_type) ; 

call  reaovc_( procref , "node/dbo/mg->proeeaa" ) ; 

call  insertf procref , "node/dbo/mg->process" , "last", 
dboref): 

call  vrite_liat_( "Resource  not  available,", 

"process  blooked."); 

call  initiate  obpl(p_pi node  name,  p_process_name, 
p_dbc_node_name , p_dbo_name , "dbo" ) ; 

return: 

end: 

/•  Check  if  the  request  is  for  shared  access  •/ 
if  p_aocess_type  e "shared" 

then  do;  /•Give  the  process  shared  access  to  the  desired 

database  objeot  •/ 


call  dcl_dbo_sh_asmt(sh_asatref); 

call  insert  Tshasmtref7  :'dbo->dbCL_sh_asat",  "first", 
dborer) ; 

call  insert_(sh_asmtref , "proeess->dbo_sh_asmt",  "first", 
procref) ; 

call  wrlte_list_(pjproces3_nane,  "at  node", 

P_P*,oc_node_name,  "granted  shared  access  to", 
p_dbo_name,  "at  node",  p_dbo_node_name) ; 

return; 

end; 

/•The  next  if  statement  will  be  executed  if  the  request  is  for 
exclusive  use  of  the  database  object  •/ 

/*  Check  if  any  process  has  shared  acoess  to  the  desired  database 
object  */ 

if  empty  (dboref,  "dbo->dbo_sh..asmt") 
then  ao: 

/•Queue  the  process  for  exclusive  use  of  the  database 
object  because  at  least  one  other  process  currently 
has  shared  access  to  the  database  .eject.  •/ 
call  alter_( procref , "process. access_type",  "exclusive"); 
call  remove  I procref,  "node/dbo/mg->processr ) ; 
call  insert  (procref,  "node/dbo/a?g->process" , "last", 
dboref) ; 

call  write  llst_( "Resource  is  not  currently  available". 

"for  exclusive  use.  process",  p_process„name) : 
call  write  list  ("  at  node",  p_jproc_node_name , 

*is  blocked.");' 

call  initiate  obpl( p_proc_node nama,  p_process_name, 
p_dbo__node_name,  p_dbo_name,  "dbo"); 

return: 
end  • 

else  do1  /•Grant  tne  Drocess  exclusive  use  of  the  desired 

database  object.  •/ 

call  insert.,  (dboref , "process->dbo" , "first",  procref): 
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call  write„list_(p_procesa„narae,  "at  node", 

P_proc_node_name,  "is  granted  exclusive  use", 
"of",  p_dbo_name,  "at  node",  p_dbo_node_name) ; 

return; 

end; 

end; 

/*  The  next  section 
resource  •/ 

/*  Verify  that  the  desired  database  objeot  exists  */ 
if  find_entity_loo(dbo_noderef , "sys->node",  SYS„REF,  p_dbo_node_name, 

"node. name") 
then  do: 


will  be  executed  when  a process  requests  a remote 


oall  write_list_( "Invalid  database  object  node  name.  ", 
P_dbo_jiode_name,  "does  not  exist."): 

return : 

end; 

eos  = fin<Lentity_J.oo(dbo_tableref,  "node->node_table" , dbo_noderef, 
p dbo  node  name,  "node_.table.name"); 

if  find_entTty_Joo(  dboref,  "node->dbo",  dbo_tableref,  p dbo_name,  "dbo.name") 
then  do; 

call  write  liat_( "Invalid  database  object  name.  ",  p dbojname, 

"at  node",  p_dbo_jode__name,  "does  not  exist."); 

return; 

end: 

eos  s find..entity_loc(dbo_tableref,  "node->node_table" , pnoderef, 
p dbo_node_name , "node  table. name"); 

/•  Check  if  the  node  containing  the  process  ia  aware  of  the  existence  of 
the  desired  database  object.  •/ 

if  find_entity_loc(dboref,  "node->dbo" . dbo  tableref,  p_dbo_name,  "dbo.name") 
then  do;  /•  Create  local  information  about  the  remote  resource  and 

block  the  process.  •/ 
oall  dcl_dbo(dboref , p_dbo_name); 

call  Insert  (dboref,  "node->dbo",  "first",  dbo_tableref ) : 
call  alterjtpror "ef , "process. access_type",  p_access_type) ; 
call  remove! procref,  "node/dbo/mg->process") ; 
call  insert_(procref , "node/d bo/mg->process",  "last",  dboref); 
end; 

else  do;  /•  Check  if  the  database  object  has  already  been  assigned 

to  the  process.  If  it  has,  print  an  error  message, 
otherwise  block  the  process.  */ 
if  inaerted_(dboref , "process->dbo") 
then  do: 

call  find  owrier_(exc_ownerref,  "process->dDo" , dborel): 
if  procrer  = exc_.ownerref 
then  do: 

call  write_list_( "Invalid  request.  Process", 
p_process  name,  "at  node", 
p_proc_noae__name , "already  has", 
-exclusive  control  of",  p_dbo_name, 
"at  node",  p_dbo_node_name) ; 

return: 

end: 


end: 

else  do: 

if  “ empty  intersection  (procref,  "process->dbo_sh_asmt" , 
dboref,  "dbo->dbo_8h_asmt") 
then  do: 

call  write_list_( "Invalid  request.  Process", 
p_ process  name,  "at  node", 

P_proc„node name , "already  has", 

"shared  access  to",  p_dbo_name, 

"at  node",  p_ dbo_node_name) • 

return: 

end: 

end: 

/*  Lestal  request,  "block"  the  process.  */ 

call  alter , 'procref , "process. access__t ypeR  , p ..access.  type} . 
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call  reaove  (procref,  "node/dbo/ng->proeeas"): 
oall  insert^  procref , "node/dbo/ng->process" , "last  , dboref): 
end: 


call  write*list_( "Process" , p_prooesa_jiaae,  "at  node",  p_proc_pode_nane, 
til  blocked  while  a request  la  sent  to"):  ^ j 

call  writ«L_li»t  (*  the  node  containing  the  desired  resource"); 

/•Create  an  entity  for  a remote  resource  request  and  then  declare  it 
as  a control  message  •/ 

call  create  entity  (re«Lreq_ref , "res_j*eq");  A 

call  oreateIattribute_Tres_rea_ref , "rea_req . aoceas.type" , "field  , 9, 

call  creatfe!tSffcte!?ri.  re<uref,  "rea^req.req^ode^aee",  "field",  12, 

oall  createZattrlSutyfealroq-Pof.  "resjreq.reqjjroq_.nMe",  "field",  12, 

call  creat *Isttribu£ejfres_reo_r« f , "res_req . deat_node_naae" , "field",  12, 

call  oreatelpMbutjEfrealre<LJref,  "reaureq . deat_dbo_naae" , "field",  12, 

call  del  oontroljwasagetrea^reqj'ef , "resjreq".  «ontJM&_nueb). 
oall  insert  (resjreqj*ef.  "aya->oontrolwjBesaafe* , "last",  SYS.^kF); 
oall  write  Iistt_J"Controi  message  nunber",  oontjiagjnunb,  "sent  fro*", 
p oroo  nodejianw , "to",  p dbo_node_na»e) ; 
call  vritelTlstjr"  representing  a renote  resource  request"); 


call  write, 
return: 
end  REQ: 
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V 

MSG ? procedure: 

/*  This  procedure  contains  the  subroutines  wnieh  perform  the 
message  management  functions  for  prooess  to  prooess  communication  within 
a network.  The  following  user  visible  functions  are  included: 

ACCEPT  MESSAGE  GROUP 
INITIATE  MESSAGE  GROUP 
RECEIVE  MESSAGE 

SEND  MESSAGE  •/ 


del  aocept_node_nane 

del  acoept_node_tableref 

del  accept_proc_name 

del  aecept_procref 

del  oont_jns&_numb 

del  eoa 

del  init_node_name 

del  init_node_tableref 

del  init_proo_name 

del  init_prooref 

del  messageref 

del  agref 

del  ndKL_proo_ownerref 

del  noderef 

del  p„acoept_node_name 

del  p_aooeptjroe_name 

del  p_init_node_naae 

del  p_lnit_proc_name 

del  p_mg_name 

del  procref 

del  rov  ■ag_nueb 

del  sendjssg_numb 

del  write_list_ 

f include  PDH_serv_rou tines : 

i include  ADT_j>rimitives; 


char(12): 
fixed  bind  7): 
char(12); 
fixed  bin(17): 
fixed  bin; 
bitd); 
char(12); 
fixed  bind 7): 
chard  2): 
fixed  bind  7): 
fixed  bim  17  / ; 
fixed  bind  7/; 
fixed  bind  7 h 
fixed  bind 7); 
chard); 
chard) ; 
ohard); 
chard): 
chard) ; 
fixed  bind 7): 


fixed  bin; 
fixed  bin; 

entry  options(variable) ; 


i 

,i 

fi 

Si 
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/• 


ACCEPT  MESSAGE  GROUP 


7/1/76  •/ 


accepting:  entry(p_mg_name,  p_accept_node_naoe,  p_aceept_proo_jiame ) ; 

^ ‘ specified  by 


/•  After  this  procedure  is  executed,  the  process  4VU  vj 

"p_accept_proc_name"  (and  located  at  the  node  specified  by 
"p_aceept_node  name")  will  be  able  to  accept  messages  in  th 
group  specified  by  "pjag_name"  •/ 

/•  If  tne  message  group  specified  by  "p_»g_name"  does  not  exis 
an  error  message  and  return  */ 

if  find_entity_loc(agref , "sys->message",  STSJREF,  p_eg_na»e, 

"message. name") 
then  do: 

call  write  list_( "Invalid  message  group  name:  " 

* does  not  exist"); 

return; 

end; 

/•  If  the  message  group  has  already  been  aooepted  by  a process,  print  an 
error  message  and  return  •/ 
if  inserted_(mgref , "rcvjproo->message") 
then  do: 

call  vrite_list_( "Invalid  aooept  message  group.  ",  p mg  name, 

" has  already  been  aooepted  by  a prooess"); 

return; 

end; 

/•If  the  node  specified  by  "p_aecept_node_name"  is  not  the  accepting 
node  that  was  specified  when  the  message  group  was  initialized, 
print  an  error  message  and  return  */ 

11  find_owner_(accepJ_node_tableref , "accept  node->measage” , mgref); 
p_accept_node_name  * extract_(aooept_norfe_tableref , "node_.table.name”) 
then  do: 

call  write  list  (j_aooept_node_name,  " is  not  the  node  that  was  ", 


ca 

if 


’specified  to  acoept  ", 
call  write  llst_(" 


sept  ",  p_j»«_name.  » when  the  message"): 

. group  was  initialized.  The  aoceptmg", 

" request  is  rejected"); 

return; 

end; 

/•  If  the  process  specified  by  "p_accept_proc_nama"  does  not  exist 
at  the  node  specified  by  "p_aooept_jiode_na»e" , print  an  error 
message  and  return  •/ 

if  find_entity_loe(accept_procref,  "node->process" , aecept_node_tableref , 
p_accept_proc_name , "process . name" ) 
then  do: 

call  write  list_( "Invalid  process  name:  ",  p_accept_proc  name, 
"does  not  exist  at  node  ",  p„accept_node_name) r 

return; 

end: 

/•  If  the  process  accepting  the  message  group  is  not  active,  print  an  error 
message  and  return  •/ 

call  fin<Lowner_(ndm_proc_.ownerref , "node/dbo/mg->prooess",  accept_procref ) ; 
if  entifcy_claas_naae_(ndiiLproc_ownerref ) e "node_table" 
then  do; 

call  write_list_( "Invalid  accepting  command.  Process", 
p_accept_proc_name , "is  not  active"); 

return: 

end: 

/*  If  the  process  accepting  the  message  group  is  the  same  one  that 
initiated  it,  print  an  error  message  and  return  •/ 
call  find_cwner  {lnit_node_tableref , "init._node->message" , mgref); 
if  inlt_node_ta'Eieref  = accopt_node_tableref 
then  do: 

/•  The  initiating  and  accepting  nodes  are  the  same.  See  if 
the  initiating  and  accepting  processes  are  the  same  •/ 
call  f ind_owner_Tinit_procref , "»endLproc->message" , mgref): 
if  inlt_procref  = accepr_prooref 
then  do 


call  write  list. ('•’Initiating  and  accepting  processes'1, 
"are  the  S3me  for  message  group  ",  p_mg_name , 


message  group 

"accenting  command  rejected1'): 
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„ end: 

/*  Insert  the  message  group  entity  into  the  accept  set  for  the  process 
specified  bv  "p  accent  oroc  nai€"  •/ 
call  insert  (mgref,  "rcv_proe-‘5message,v,  "first",  acoept_procref ) ; 
call  write  Tist_(pjag_naae,  " has  been  aooepted  by  ",  p_accept_proc_name , 
" at  node  "7  p_aocept_node_name) ; 

return: 


/•  INITIATE  MESSAGE  GROUP  7/1/76  •/ 

ir.it mg:  entry ( pj*g_naae , p init_node_name , p_init_proe_name , 
p_acoept_node_nam€ ) : 

/*  This  procedure  will  create  a message  group  with  the  global  name 
specified  by  "p_jBg_naae" . The  only  process  that  can  send  messages 
in  this  message  group  is  specified  by  "p^initnroojiame"  and  is  located 
at  the  node  specified  by  "p_init_node_naoe",  The  prooess  that  will 
receive  messages  in  the  given  message  group  is  located  in  the 
node  specified  by  "p_accept_node_name".  The  speoiflc  prooess  that  will 
accept  the  messages  will  be  given  in  a subsequent  call  to  "aoceptmg" 
bv  the  user.  •/ 

/*  Ir  we  have  a duplicate  message  group  name,  we  must  print  an  error 
message  and  return  •/ 

if  find_entity_loo(mgref,  "sys->message",  SYS_J?EF,  p_jBg_name,  "message. name") 
then  do; 

call  write  list_( "Duplicate  message  group  name,  initmg", 

"command  rejected"); 

return: 

end; 

/•  If  the  node  specified  by  "p_initjnode_name"  does  not  exist,  print 
and  error  message  and  return  */ 

if  find_entity_loo(noderef,  "sys->node",  SYS_REF,  p_init_node_name, 

"node. name") 
then  do; 

call  write  list_( "Invalid  node  name:  ",  p_init_node__name, 

T does  not  exist"); 

return; 

end; 

/•  Get  the  location  of  the  node_table  for  "p_init_node  name"  */ 

eos  * find_entity_loc(init_node  tableref,  "node->node_table" , noderef, 
p_init_node_name , "node_table. name") ; 

/•  If  the  process  specified  by  "p_init_proc_name"  does  not  exist  at  the 
node  specified  by  "p_init_node„name"  then  print  an  error  message 
and  return  */ 

if  find_entity  locCprocref,  "node->proeess",  init_node_tableref , 
p_init_proc„name , "process. name") 
then  do; 

call  write  list_( "Invalid  process  name:  ",  p_init_proc_name, 

" does  not  exist  at  w,  p_init_node„name) : 

return: 

end: 

/*  If  the  process  specified  by  Hp_init_proc_name''  is  not  active,  print 
an  error  message  and  return  */ 

call  find_ownerjndm_proe_ownerref,  "node/dbo/mg->process" , procref); 

if  entity_class_name_vndm_proc_ownerref)  *=  "node,  .table" 
then  do: 

call  write_list  ("Invalid  initmg  command.  Process  ", 
p_init_proc_narae,  " is  r.ot  active"): 

return; 

end: 

If  the  node  specified  by  "p.„accopt_.node_name"  does  not  exist,  print 
an  error  message  and  return  */ 

if  find_entitv_loc( noderef , "sys->node",  SYS_REF,  p_accept_node_.name, 

"nods. name") 
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p_aocept_node_name , 


then  do: 

call  write  list_( "Invalid  node  name: 

" does  not  exist"): 

return: 
end: 

/•  Get  the  location  of  the  nodetable  for  " paooep  t_node„naa« 
eos  = find_entityJLoc(aceept_po?e_tableref,  "node->node_tabl« 
p_aeoept_node jim»  , "noa«s_table . naae" ) ; 

/*  Create  an  entity  for  a message  group,  create  the  necessary  relationships 
and  attributes,  and  insert  the  entity  into  the  appropriate  sets  */ 
call  create_entity_(agref.  "message"); 

tlonsniP_(mgref , "sys->» 


bc"  •/ 

Le",  noderef, 


call  create_.relationshio_ 
call  create_relationship_ 
call  ereate_relationship_ 
call  ereate_relationship_ 
call  ereate_relationship_ 
call  create_relationship__ 


-0-  ~ , rys->aessa«e",  "Benber"): 

Bgref,  "init_jnode->Bessage" , "member"); 
ngref,  "accept_nsde->Bessage",  "aenber"); 

Bgref,  "send_proci->message",  "member"); 
mgref,  "rcv_proc->message",  "member"): 

_ _ Bgref,  "node/dbo/mg->prooesa" , "owner"): 

call  oreate_attribute_(mgrer,  "massage. nunber_sent",  "field".  4.  "C"); 
call  create_attribute_(Bgrcf,  "message. nuaber_qd",  "field",  *0"): 
oall  cr*ate_attribute_(Bgrsf , "Bessage.nuBber_.rovd".  "field",  4,  "0"): 
call  create_cttribute_tBgref,  "message. naae" , "field",  12,  p_mg_name); 
call  insert  Tmgref,  "sya->«essage",  "first".  SYS  PBF): 
call  insert  fagref,  "init_jnode->message",  "first".  init_node_tabiuref ) ; 
call  insert  (Bgref,  "aoc*pt_node->message"1  "first",  accegt_node_tableref ) : 


'aocept_node->message",  "first  _ 

uoii  xn0vrv_\uf  v.  ■ 'send  proo->aessage  , "first",  prooref): 
call  vrite_Tist_( "Message  group  ",  p_mg_raBe,  "has  been  initiated"); 
return: 


call  insert  (a*. i ef. 
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/•  RECEIVE  MESSAGE  7/1/76  */ 

rcvmsg : entry  ( pjmg_name ) ; 

/•  this  procedure  will  simulate  the  receiveing  of  a message  in  the  message 

froup  specified  by  "p  mg  name"  •/ 

f the  message  group  specified  by  "p.jng*.name"  does  not  exist,  print 
an  error  message  and  return  •/ 

if  find_entity_loc(mgref , "sys->mesaage",  SYS_REF,  p_mg_name,  "message. name") 
then  do: 

call  write  list__( "invalid  message  group  name:  ",  p„m&_name, 

* does  not  exist"); 

return; 

end; 

/*  If  no  prooess  has  aooepted  the  message  group,  print  an  error  message 
and  return  */ 

if  inserted_(mgref , "rcv_j)roo->message") 
then  do; 

call  write  list_( "Invalid  rcvmsg  oommand.  No  prooess  has", 
"accepted  message  group  ",  p_mg_nama): 

return; 

end; 

/•  Get  the  name  and  node  of  the  prooess  that  should  reoeive  the  message  */ 
call  find_owner_(acoept_procref,  "rov_jjroo->raessage" , mgref); 
aeceptproc_jname  a extract  (aocept_procref,  "process. name" ) ; 
call  find  owner_(accept_jjoae_tableref , "aeeept_node->message",  mgref); 
accept  node_name  a extraet  (acoept_noae_tableref,  "node  table. name"); 

/*  If  the  process  specified  by  "aocept_proc_name"  is  not  active,  print 
an  error  message  and  return  •/ 

C'll  find_owner_(ndmDroc_ownerref,  "node^dbo/mg->process" , accept_procr-ef ) : 
if  entity_class_name_tndm_proc_ownerref)  a "noae_table" 
then  do: 

call  writeJList  ("Process",  accept_proc  name,  "at  node", 

aocept  node_naae,  "is  not  active.  No  message  can  be"): 
call  write„list_T"  received  in  message  group",  p_mg_name); 

return; 
end; 

/(l  Find  out  if  the  message  can  be  received,  or  if  the  process  must 
be  blocked  •/ 

rcv_msg_numb  * extract_(mgref , "message. number  rcvd") : 
if  rev msgnumb  < ext  ract_(  mgref , "message. number_qd") 
then  ao : 

/•  Allow  the  process  to  receive  the  message  */ 
rev  ms«  numb  = rov_msg_numb  +1: 

call  alter_( mgref , "message. number_rcvd",  rcv_msg_numb) ; 
call  write_list_( "Process",  accept_proc  rams,  "at  node", 
accept  node_name , "has  received"); 
call  write_list_T"  a message  in  message  group",  p_mg_narae): 

return: 
end: 

else  do: 

/*  Block  the  process  •/ 

call  remove_(accept_procref , "node/dbo/mg->process") : 
call  insert_(accept_procref , "node/dbo/mg->process",  "first", 
mgref) : 

call  write_Iist_( "Process  ",  acoept_proc_name,  "at  node", 
accept  node_name,  "is  blocked  waiting  for  a"): 
call  write_list_T"  message  in  message  group",  p„og_name): 

/*  Get  the  name  of  the  node  that  initiated  for  "owns")  the  message 
group  */ 

call  find_owner_(init_.node  tableref,  "init_node->message" , mgref): 
init  node  name  = extract_(Tnit_node_tableref , "node„table.name") : 

/•  Check  for  deadlock  V 

call  inltiate_obpl(accept_jiode_r,ame,  accept_proc__name, 
init_node_name,  p.mg_name,  "message"): 

return: 

end: 
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/*  SEND  MESSAGE  7/1/76  •/ 

sendmsg:  entry(p_mgname) ; 

/*  This  procedure  will  simulate  the  sending  of  a message  in  the  message 
group  specified  by  "p_jng_name"  */ 

/•  If  the  message  group  specified  by  "p.j>g_name"  does  not  exist,  print 
an  error  message  and  return  */ 

if  fin<L.entity_loc(mgref , "sys->message",  SYSJREF,  pjagjname,  "message. name") 
then  do: 

call  write  list_("Invalid  messags  group  name:  ",  p_mg_name, 

"does  not  exist"); 

return: 

end; 

/•  Verify  that  the  process  that  should  send  the  message  is  active  •/ 
call  find_own.e:  _(init_procref , "send_proc->measage",  mgref); 
call  find_owner_(ndaL.proc_ownerref,  "nod$/dbo/mg»>proeesa",  init„_procref ) : 
if  entity_class_mme_indnLproc_ownerref)  * "node__table" 
then  do: 

/•  The  process  that  should  send  the  message  is  not  active.  Get 
its  name  and  node  and  print  an  error  message.  */ 
call  find_owner_(init_node„tableref,  "init_noae->measage",  mgref); 
init_node_name  * extract  (init_nr>de_tableref,  "node_table.name"); 
init_proc_jname  = extraet_(inlt_procref » "process. name"): 
call  write  11 st_( "Process  ",  init  _proc_name , " at  node  ", 

Tnit  node_name,  " is  not  aetive.  No  message  can  be  "); 
call  write_list_('"  sent  in  message  group  ",  p_jag_name) ; 

return; 
end; 

/•  Add  1 .o  the  number  of  messages  sent  in  this  message  group  */ 
send_msg_numb  * extract_(mgref , "message. number_sent";  ♦ 1; 
call  alter  (mgref,  "message. number._sent" , sencLmsgnumb) ; 

/•  Find  out  if  the  message  must  be  sent  between  nodes  •/ 
call  find_owner  (init_noae  tableref,  "init_node->message",  mgref); 
call  find_owner  (accepjj_noae_table»*ef . "aocept_node->message",  mgref); 
if  lnit_node_tableref  e aecept_node_fcablerer 
then  do: 

/*  Send  a control  message  stating  that  a message  has  beer  sent  in 
the  message  group  specified  by  *p jngjname"  »/ 
call  create_entity_(messag*r’ef , "msg"); 

call  create„attribute_(messagei  ef , "msg.mg_name" , "field",  12, 
p„mg_name) ; 

call  dcl_controljBessage(measageref , "msg",  cont  jBsg_numb) ; 
call  insert_(messageref , "sya->control_jnessage" , "last",  SYS_REF); 

/*  Get  the  names  of  the  nodes  involved  •/ 

init_node  name  s extract_(init_node_tableref , "node_table.name") ; 
accept__noae_name  « extract  (accept_node_tableref , 

"node_table . name") : 

call  write  list  ("Control  message  number  ",  cont_jnsg_numb , 

w sent  from  ",  init_node_namt;f  "to  ",  accept_node_name) : 
call  write  list_("  representing  a message  in  a message", 

"group" ) ; 

return; 

end: 

/•  If  the  next  section  of  code  is  executed,  then  the  message  should  be  sent 
between  processes  at  the  same  node  */ 

/*  The  number  of  messages  queued  equals  the  number  of  messages  sent  because 
there  is  no  delay  across  any  node  */ 
call  alter_(mgref , "message.number_qd",  send_msg_numb) , 
call  wrlte_list_("A  message  has  been  sent  in  message  group  ",  p_mg_name): 

/*  If  no  process  has  accepted  the  message  group,  return  rather  than  see  if 
a process  should  be  woken  up  */ 

If  A inserted_( mgref , "rcv..proc->message") 
then  return: 

/*  If  a process  is  waiting  for  this  message,  wake  it  up  and  let  it  "receive" 
the  message  */ 

call  f ind.„owner. i«ecept_procref , "rcv_proe->message" , mgref): 

call  f ind„owner_(ndm_proc_ownerref , "node/dbo/mg->process" , accept  procref): 

If  ncm  .proo  ownerref  = mgref 
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then 


return: 
end  MSG: 


do; 

/•  Wake  up  the  process  pointed  to  by  "aeoeptproeref"  •/ 
call  reBove_(aooept_procref,  "node/d bo/mg->prooess") ; 
oall  insert_(aooept  orooref , "node/dbo/mg->process" , "first", 

..  __  . aoeeptLnb3^.tabIeref); 

/•  "Receive"  tne  message  •/ 

r°T  asKnumb  * extraot_(agref,  "message. nuaberjrcvd")  + 1; 

*iver_(«gref , "message. number  read",  revjBsgjiueb) ; 

/•  Get  the  name  or  the  prooess  thaF  was  awakened  •/ 

*ooept_node_ name  * extraot_(  &ccept_node_tableref , 

"node_table . name*) ; 

acoeptjproc^naae  * extract  (aocept_prooref , "process. name") ; 
call  witO^iet  ("Prooess",  accept. proc_name,  "at  node", 

,,  eccep tjjode_nasie , "has  been  awakened  upon"); 

call  wrlte_list_J"  receipt  of  a message  in  message  group", 

^ P_®R_naae; ; 

end; 
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OP  CON:  procedure; 

/•^ This  procedure  contains  subroutines  which  oreate  an  operator  connection, 
allow  the  operator  to  send  messages  over  the  connection,  allow  the 
operator  to  receive  Messages  over  the  connection,  and  allow  the 
operator  to  report  its  status  (active  or  blocked)  with  respeot  to  the 
operator  connection.  The  following  user  visible  functions  are  included: 
CREATE  OPERATOR  CONNECTION 
OPERATOR  MESSAGE 
OPERATOR  STATUS 

RECEIVE  OPERATOR  MESSAGE  */ 


UVA 

{include 
Include 


coit.opref 

eos 

nda_proc_ownerref 

node ref 

node_tableref 

nuaberqd 

obplrer 

op_oonref 

opref 

P_oon_naaje 

p_oon_.node_naae 

p_op_nane 

p„op_node_nane 

p_procea8_nase 

process  name 

proc_noae_na»e 

prooref 

p..state 

tableref 

write_list_ 

DDM_serv  routines : 

ADT_prinitive3: 


fixed^bin(IT); 

fixed  6in(17)? 
fixed  bin? if); 
fixed  bin(lt): 
fixed  bin: 
fixed  bin( 17); 


fixed  bint  17) ; 

fixed  bint  17): 

ehar(*); 

char(*  (: 

chart* 

chart*,  ; 

chart*): 

chart  12); 

ehar(12); 

fixed  bin(1 7): 

ehar(*) : 

fixed  bin( 17): 

entry  options(variable): 


copcon*  entry?  p_eonnane,  p_oon_node_name , p_op_naae,  p_prooess_naee) ; 

/•  This  procedure  will  create  a connection  between  the  operator  specified 
by  "p_op_name"  and  the  process  specified  by  "p_process_name",  both 
located  at  the  node  specified  by  "p_op_node_na»e".  The  connection  will 
be  aiven  the  name  specified  by  "p_eorv_naae"  •/ 

/*  If  we  have  a duplicate  operator  connection  name,  print  an  error  message 
and  return  •/ 

if  find_entity_loc(op eonref,  "sys->op_con" , SYS_REF,  p_oop_name, 
*op_con.name"ji 
then  do: 

call  write  list_( "Duplicate  operator  connection  name.", 

"Command  rejected"'; 

return; 

end: 

/*  If  the  node  specified  by  "p_corunode_naae"  does  not  exist,  print  an 
error  message  and  return  */ 

if  find_entity_loc(noderef , "svs->node" , SYS_REF,  p_con_node_name , 

"node .name" ' 
then  do: 

call  write list_( "Invalid  node  name:",  p_cop_node_name, 

"does  not  exist"): 

return: 


CREATE  OPERATOR  CONNECTION 
Bntry(p_eon_nane,  p_con_nodt 


7/9/76  •/ 


/•  Cet  the  location  of  the  node_table  for  "p_con_node_name"  */ 
eos  - find_ entity_loc(node„tableref , "node-;node_table" , noderef, 
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P_oon_.node_.name,  "node_table.name") : 

/•If  the  node  is  unaware  of  the  existence  of  the  operator,  print  an 
error  message  and  return  */ 

if  find_entity_loo( opref . "node->operator" , node_tableref,  p_op__name, 
"operator. name") 
then  do; 

call  write_list_( "Invalid  operator  name:",  p_op_name, 

Tdoes  not  exist  at  node",  p_eon_jioae_name) ; 

return; 

end; 

/•  If  the  process  specified  by  "p_prooess_name"  does  not  exist  at  the 

node  specified  by  "p_con_node_name",  print  an  error  message  and  return  •/ 
if  find_entity_loc(procref1  "node->proce§3",  node_tabler-ef, 

P_ proeesa_name , "process. name") 
then  do; 

call  write  list_( "Invalid  process  name:",  p_process  name, 

"does  not  exist  at  node",  p_con_node_nameT; 

return; 

end; 

/•  If  the  process  specified  by  "p_proeess_name"  is  not  active,  print  an 
error  message  and  return  •/ 

call  find_owner_(ndm_proo_ownerref,  "node^dbo/mg->process" , procref); 
if  entity_class_name_(ndnLproc_,ownerref)  s "node_table" 
then  do: 

call  write  list_( "Invalid  copcon  command.  Process",  p jprt>eess_name, 
■"is  not  active"); 

return; 

end; 

/•  Create  an  entity  for  an  operator  connection  and  insert  it  into  the 
proper  sets  9/ 

call  create_entity_(op oonref,  "op  con"); 

call  ereate_attribute  fop_oonref,  "op_con.name",  "field".  12,  p oonname); 
call  create_attribute  '.cp_conref,  "op_eon.number_qd",  "field",  1*.  "0"); 


call  create_j'eiationahlp_lop_conrer.  "sys->op_oon" , "member";; 

call  create_relationship  (op_oonref,  "node/dbo/mg->process"  "owner"): 

call  insert  _(op_conref,  "prooess->op_oon".  "first",  procref); 

"first",  opref); 


call 
call 
call 
return; 


REF); 

"has  been  established"); 
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OPERATOR  MESSAGE 
itry(p_conname): 


isg:  entry(p_con_name 
This  procedure  will  e 


AGE  7/13/76  •/ 

|Q  j • 

cause  a message  to  be  sent  from  an  operator  to  a 


/»  This  procedure  will  oause  a message  to  be  sent  from  an  operator  to  a 
process  over  the  operator  connection  specified  by  "p_eon_na»e" . If  a 

Erocess  is  waiting  for  this  message,  it  will  be  awakened  and  given 
he  message,  otherwise  the  message  will  be  queued.  Any  OBPL's  that 
were  waiting  for  state  information  about  the  operator  with  respect  to 
this  operator  connection  will  be  discarded  since  the  operator  is  active  */ 
/*  If  the  operator  connection  specified  by  "p_eon_naae"  does  not  exist, 
print  an  error  message  and  return  */ 
if  fitid_entity_loc(op_conref,  "sys->op_con",  SY$_REF,  p_eon_name, 
"op_con.naae") 
then  do: 

call  write_list_( "Invalid  operator  connection  name:", 
p_con_name,  "does  not  exist*): 

return: 

end; 

/•  Discard  any  OBPL's  that  were  waiting  for  state  information  from  the 
operator  that  sent  the  message  */ 
call  find_owner_( opref,  "operator->op_con" , op_eonref): 
call  find  first_(obplref , "operator->obpl",  opref,  eos): 
do  while  T eos): 

call  removefobplref.  "operator->obpl"); 

call  find_first_(obplref , "operator->obpl",  opref,  eos): 

end: 

/*  If  no  process  is  waiting  for  the  message,  queue  it  an  return  •/ 
if  empt.y_(op_conref , "node/dbo/mg->prooess" ) 
then  do: 

number  qd  a extraet_( op  conref,  "op_oon. number  qd")  ♦ 1; 
call  aTter_( op  conref,  "op_con.number_qd",  number_qd); 
call  writeliat  ("No  process  is  waiting  for  the  message,", 

"so  it  is  queued"); 

return: 

end: 

/*  A process  is  waiting  for  the  message,  so  we  must  wake  it  up  •/ 

call  find_first_(procref,  "node/dbo/mg->proceas",  op_oonref,  eos); 

call  remove_( procref,  "node/dbo/mg->proceaa") ; 

call  find_owner_(tableref , "node->process" , procref): 

call  lnsert_( procref , "node/dbo/rag->proceas" , "first",  tableref); 

/•  Get  the  name  of  the  process  that  was  awakened  */ 
process  name  = extraet_(procref , "process. name*); 
proc_noae_name  = extract_( tableref,  "node_table.name") ; 
call  write  list_(process  name,  "at  node",  proc__node__name , "has  been", 
"awakened  upon"); 

call  write_.list_("  receipt  of  a message  over  operator  connection", 

P-_con_name) : 

return: 
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/•  OPERATOR  STATUS  7/14/76  •/ 

opstat:  entry (p_op unode_naae,  p_op_name,  p_state,  p_corL.name) : 

/*  This  proeedure  will  take  the  appropriate  action  when  an  operator 
reports  that  it  is  "aotive"  or  "waiting"  */ 

/*  If  the  node  specified  by  "p_op_node_name"  does  not  exist,  print  an 
error  message  and  return  */ 

if  fir«d_eritlty_loe(noderef , "sys->node" , SYS__REF,  p_op_node_name, 

"node. name") 
then  do; 

call  write  list__( "Invalid  node  name;",  p_op_node_narae , 

"does  not  exist"); 

return; 

end; 

/•  Get  the  location  of  the  node  table  for  the  node  specified  by 
" P_op_node_name " */ 

eos  s fin<L.entity  loc(tableref,  "node->node  table",  noderef, 
p_op_noce_name , "node_table.naae"T; 

/•  if  the  operator  specified  by  "p  op.jaame"  does  not  exist  at  the  given 
node,  print  an  error  message  ana  return  */ 
if  find_entity_loc( opref , "noae->operator" , tableref,  p_op_name, 
"operator. name") 
then  do: 

call  write  list_( "Invalid  operator  name;",  p_op_name, 

"does  not  exist*); 

return; 

end: 

/•  If  the  operator  is  active,  we  can  discard  all  OBPL's  that  desired  this 
state  information,  and  then  return  */ 
if  p_state  a "active" 
then  do; 

call  find_first  (obplref,  "operator->obpl",  opref,  eos); 
do  while  ( eosT; 

call  remove  (obplref . "operator->obpl"); 

call  find_first_( obplref,  "operator->obpl",  opref,  eos): 

end: 

call  write_list_("All  OBPL's  waiting  for  the  given  state", 
"information  have  been  discarded"); 

return: 

end: 

if  p_state  = "waiting" 
then  do: 

call  write  list_("Invalid  state.  An  operator  can  only  be", 
"active  or  waiting"); 

return; 

end: 

/*  If  the  operator  connection  specified  by  "p_con_name"  does  not  exist, 
print  an  error  message  and  return  because  one  can  not  wait  for  a 
message  over  a non_existent  operator  connection  •/ 
if  find_entity_loc(op_conref , "sys->op__con" , SYS_REF,  p_con_name, 
"op_con.name") 
then  do: 

call  write_list_( "Invalid  operator  connection  name:", 
P_con_name,  "does  not  exist"): 

return: 

end: 

/*  If  the  operator  specified  by  "p_op_name"  Is  not  involved  with  the 
operator  connection  specified  by  "p_con_name",  print  an  error  message 
and  return  •/ 

call  findwowner_(con  opref,  "operator->op„con" , op_conref): 
if  opref  w=  con_opref 
then  do* 

call  write  list_(p_op_name,  "at  r.ode",  o_op_node_namc , 

"is  not  associated  with  operator  connection", 
p_.con__name ) • 

return* 
end  • 

call  write..  llst_("We  will  now  check  for  deadlock  involving  the  Riven", 
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"operator"): 

call  write_llst_("  and  operator  connection"); 

/•If  the  process  that  can  send  messages  over  the  operator  connection 
specified  by  "p  eon  name"  is  active,  there  is  no  deadlock,  so 
discard  all  OBPL’s  that  requested  the  given  state  information  */ 
call  find_owner_(procref , "process->op_con".  op_eonref); 
call  find_ovmer_{ndBjroc_ownerref,  "node/dco/mg->process" , procref): 
if  entity_class_nameZ(ndm_proc_ownerref)  * "node_table" 
then  do: 

call  find  first  (obplref,  "operator->obpl",  opref,  eos); 
do  while 
o*U 
call 
end; 
return; 
end; 

/•  If  there  are  no  OBPL's  waiting  for  state  information  about  this 

operator,  create  an  09PL  with  the  operator  as  the  only  process  entry  •/ 
if  empty_(opref , "operator->obpl") 
then  do: 

call  dcl_obpl (obplref,  p_op_node_jname , "",  "opjnsg"); 
call  dcl_proc_entry( obplref , p_op_nodejname,  pT_cp_naae) : 
oall  insert__( obplref,  "operator->obpl",  "first'*,  opref); 
end; 

/•  Find  out  the  name  of  the  prooeas  that  can  send  the  message  the 
operator  desires  •/ 

procesa_name  * extract_(  procref,  "process. name"): 

/•  Expand  each  OBPL  that  required  state  information  about  the  given 
operator  •/ 

call  find  first_( obplref,  "operator->obpl",  opref,  eos); 
do  while  T eos); 

/*  Remove  the  OBPL  from  the  set  belonging  to  the  given  operator  •/ 
call  remove_(obplref , "operator->obpl'') ; 

/*  Check  if  we  nave  a deadlock  •/ 

call  check_for_deadlock(obplref,  p_opnode_naae , prooesa  name,  eos); 
/*  If  eoa  a 1,  then  a deadlock  was  not  detected,  so  we  should  add  a 
resource  to  the  OBPL  and  then  expand  it  •/ 
if  eos 

then  do; 

call  obpl_add_reaource(obpiref , ndm_proc_ownerref, 
P_op,_node_name , eos); 

/•if  eos  = 1 then  the  resource  the  process  is  waiting  for 
is  in  the  same  node  aa  tha  prooeas,  so  we  can  continue 
to  expand  the  OBPL  •/ 

If  eoa 

then  call  exp_ofcpl(obplref , p„op_node  name); 

end; 

/*  See  if  there  are  any  more  OBPL's  to  be  examined  •/ 
call  find_first_(obplref,  "operator->obpi",  opref,  eos); 
end; 
return;. 


\ WWW  / 


remove  (obplref . "op«rator->obpl") ; 
find_fTrs't_(  obplref , "operator->obpl" , 


opref,  eos); 
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Procedure  OP„.CON 


RECEIVE  OPERATOR  MESSAGE 


rcvopmag : entry { P_con_nane 


7/13/76  •/ 


/*  This  prooedure  will  simulate  the  receiving  of  a message  by  a process 
over  the  operator  connection  specified  by  "p_con_name"  •/ 

/•  If  the  operator  oonneotion  specified  by  "p_conjname"  does  not  exist, 
print  an  error  message  and  return  */ 
if  find_entity_loo(op_conref , "sys->op_eon" , SYSL.REF,  p_oon_name, 
"op_oon.name") 
then  do: 

call  write_list_( "Invalid  operator  connection  name:",  p_oon_nanse, 
"does  not  exist"); 

return; 

end; 

/•  Get  the  name  and  node  of  the  process  that  should  receive  the  message  »/ 

call  find_owner_( proeref , "procesa->op_oon" , op  conref); 

process_name  « extract_( proeref,  "process. name"T; 

call  find_owner_(tableref.  "node->process".  proeref): 

proc  node_na»e  * extraet_(tableref,  "node_table.name") ; 

/•  If  the  prooess  is  not  active,  print  an  error  message  and  return  */ 
oall  find_owner_(ndsLProci_ovnerrer,  "node/dbo/mg->proceas",  proeref); 
if  entity_olass_n«aa_ind3LproA_ownerref)  « "noae_table" 
then  do: 

call  vrite_liat_( "Process",  prooess_name , "at  node", 

proc  node_name,  "is  not  active.  No  message  can  be"); 
call  vrite_list  ("  reoeived  over  operator  connection", 

p_oor<_name) ; 

return; 

end; 

/*  Find  out  if  the  message  can  be  reoeived,  or  if  the  process  must  be 
blooked  •/ 

number  qd  » extract_(op_oonref,  "op_con.number_qd") ; 
if  nuoSer_qd  > 0 
then  do; 

/•  Remove  one  message  from  the  queue  */ 
number  qd  * number_qd  - 1; 

call  aTter_(op  oonref,  "op_oon. number _qd",  number  qd); 
call  write_list_(process_name,  "at  node",  proc_nooe_name , 

"has  received  a message"); 

oall  writc_Ust„("  over  operator  connection",  p_corv_name); 

retur  <; 

end; 

else  do: 

/•  Block  the  prooess  and  initiate  processing  of  an  OBPL  •/ 
call  removef proeref,  "node/dbo/mg->oroeess") : 
call  inaert_(prooref,  "node/dbo/mg- >process",  "first", 
op  eonrof ) ; 

call  write_lTst_("Process",  process_name . "at  node". 

proc_node_name , "is  blocked  waiting  for  a"); 
call  write_list_("  message  over  operator  connection", 

P„oon  name) : 

call  initiate_ODpl(proc_node_name,  process_name,  proc_node_name , 
p_coq_naoe,  "op_msg"): 


retur*n; 

end; 

end  OP  CON: 
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Procedure  RCV_CM 


^ * 

RCV_CM.  procedure^  _roc0<jure  la  ft  00neotion  of  subroutine*  whieh  will  scoept 
a control  message  and  take  the  appropriate  aotion.  The  following  user 
visible  function  is  included: 

RECEIVE  CONTROL  MESSAGE 
The  following  support  routines  are  included: 

PROCESS  MESSAGE 

PROCESS  OBPL  PASS 

PROCESS  "PROCESS  TERMINATION" 

PROCESS  RESOURCE  GRANT 
PROCESS  RESOURCE  RELEASE 
PROCESS  RESOURCE  REQUEST  */ 


del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

^include 

^include 


accept_node_name 

aocept_node_tableref 

accept_proe_name 

acceptbrocref 

acoeas3ype 

eont_>nag_nunb 

cont_jBSgref 

cont _S>sgL_type 

dbo_jiaae 

dbo_node_name 

dbo_ncder»f 

dboref 

dbo_t able ref 

eos 

mgjnaae 

mgref 

ndm nroe_ownerref 
obplref 

p_eont_msi_numb 

p.jusgref 

p_obol_passref 

p_res_grantref 

p_res_relref 

p_res_reqref 

process  name 

proe_noae_name 

proc„noderef 

proeref 

proc_  tableref 

qd_mag_numb 

rev  mag . numb 

rcv_noae._name 

ah  asmtref 

writ«_llst_ 

DDM_serv  rout  ines : 
ADT_prialtives: 


chard  2): 
fixed  bin(17); 
charT 12);  t 
fixed  bind?); 
ehar(9); 
fixed  bin:  , 
fixed  bin(17): 
ehar(20 
char  12 
chard2. 
fixed  bind  7 
fixed  bind  7 
fixed  bind? 
bitd): 
chart  12); 
fixed  bind? 
fixed  bind  7 


fixed  bind? 
chard): 
fixed  bind  7 
fixed  bin  17 
fixed  bind? 
fixed  bin(17 
fixed  bin(17 
char(12); 
ohar(12): , 
fixed  bind  7) 
fixed  bin(17 
fixed  bindt) 
fixed  bin; 
fixed  bin; 
chard  2) : 
fixed  bin( 17) : 
entry  optional  variable) ; 


/*  RECEIVE  CONTROL  MESSAGE  6/15/76  */ 

receive_control_messag6:  revem:  entry(p_cont_msg_numb) : 

/•  This  procedure  will  verify  that  the  control  message  which  has  its  number 
specified  by  "p  cont  msstnumb"  has  been  sent,  but  has  not  been  received 
The  procedure  will  tHen  determine  what  type  of  control  message  it  is,  and 
the  appropriate  subroutine  will  be  called  to  act  on  the  message.  */ 
call  find  first_(cont_msgref , "sys~>control_fflessage" , SYSJREF,  eos): 

/«  Convert  the  control  message  number  from  a character  string  to  a numeric 
value  */ 

cont_msg„numb  = p_eont_msgt_numb: 
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Procedure  RCV_CM 


do  whllet(*eos)^’r01  nes8a8e  with  nunber  specified  by  "p_cont_jB8g_nurab"  */ 

eXthent3o°0n^~n88^*^,  "control_jBeaaage , number")  s cont_msg_numb 

/*  Remove  the  oontrol  message  frctn  the  aet  of  oontrol  messages 
so  that  this  control  message  will  not  be  received  a seoond 
tlnct  */ 

call  removejoont  msgref , "sya-^controljnesaage" ) ; 

/•  Find  out  what  type  of  control  message  it  is,  and  call  the 
routine  that  will  take  the  appropriate  action  */ 
oont_mag_type  # entity_claas_name_(eont_jnagref) ; 
if  oont_jasg_type  * "mag" 
then  do: 

call  write_l 1st  ("Control  mesaage_jnumber" , 

p cont_jBsg_numb,  "representing  a message", 
"in  a message  group"); 

call  vrite_list_("  has  been  received"); 

call  prooe88_m8g(cont_msgref) ; 

return; 

end; 

if  cont_mag_type  * "obpl_pass" 
then  do: 

cell  writOiat  ( "Control  message  number", 

%as  been^eceiv  jr«^r*8®ntin*  ®n  0BpL,,t 
call  procsss_obpl_pass(cont_msgref ) ; 
return; 
end; 

if  cont_msg_type  * *res_grant" 
then  do; 

call  write_list  ("Control  message  number", 

p_cont_msgLnurab , "representing  a remote", 
"resource  allocation"): 

call  write_list_("  has  been  received"); 

call  process_.res_grant(cont_msgref) ; 

return: 

end; 

if  eont_mag_type  * "res_rel" 
then  do; 

call  write_list  ("Control  message  number", 

p_con\\jnsg_numb , "representing  a remote", 
"resource  release"): 

call  write_liat_("  has  been  received"); 

call  proces3_res_rel(eont_msgref) : 

return; 

end; 

if  cont_msg_  tv^e  = "res  req" 
then  do: 

call  write_list_( "Control  message  number", 

p_cont_ms&_nuob , "representing  a remote", 
"resource  request"); 

call  write_list_("  has  been  received"); 

call  procesa_res_req(cont_msgref 5 : 

return: 

end; 

end: 

call  find_next_.(eont_msgref , "sys-''control  jnessage"  , eos): 
end; 

/*  If  "p_cont_msg_numb-'  didn't  match  any  control  message  number,  then  we 

"stu  “ ' 


return 


should  print  an  error  message  and  rslurn  •/ 

: list ( p cont_ms 

" Command  reject 


call  writeirlist_(p_rcont_msg^nyffib,  " is  not  a valid  control  message  number." 
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Procedure  RCV_CM 


If  a process 
the  message 


/•  PROCESS  MESSAGE  7/1/76  •/ 

process_msg;  encry(piAsgref ) • 

/*  This  procedure  will  receive  a message  in  a message  group, 
is  waiting  for  this  message,  it  will  be  woken  up,  otherwise 
will  be  "queued*  •/ 

/*  Gat  the  name  and  location  of  the  message  group  ■/ 

«R_na»e  * extraet.Jp  msgref,  "msg.Mg.naae"}; 

eos  * find  entity_loc(«gref , "sys->measage*,  SYS_RBF,  mg_n*une, 

"message. name"); 

/•  Acknowledge  receipt  of  the  message  by  adding  1 to  the  number  of  messages 
that  have  been  queued  in  this  message  group  •/ 
qd  msg:  numb  * extraetjmgref , "message. nuraber_qd")  ♦ 1; 
call  alterjmgref , "message,  mwber.qd",  qcuasgjrnimb) ; 

/•  if  no  process  has  accepted  the  messigo  group,  return  •/ 
if  insert  edj  mgref,  "rcv_proc-imeasage") 
then  do: 

call  write  liatj "Message  group",  mg_naae,  "has  not  been", 
"accepted.  The  message  is  queued."): 

return : 

end;  , 

/•  Get  the  name  and  node  of  the  process  that  can  receive  the  message  ■/ 


____  meuii  11UUH,.  lai/APrmt  y •wwwpwjivwm-' rarewuapv  y mgref) ; 

accept_no?e„name  = ex£raotjaoeept_nooe_tableref,  "node_t able. name") ; 

/*  Keep  the  message  queued  if  the  process  is  not  waiting  for  it.  Otherwise 

call*f in§_owner^?nd^proe_ownerref , "node/dbo/mg->process" , accept_procref ) : 
if  ndm_proc_ownerref  * mgref  _ 

then  call  write  list_("Ho  process  is  waiting  for  the  message,", 

"so  it  is  queued"); 

else  do: 

call  r«move_(aecept_procref,  "node/dbo/mg->process") ; 
call  i nsert_( accept  procref,  "node/dbo/ag->process" , "first", 
accept  no'3e_tableref): 

rev  ms*  numb  s ext ract_( mgref , "message. number_rcvd")  ♦ 1; 
call  alFerJmgref,  "message. number _rcvd",  rev_msg_numb) ; 
call  write_list  ("Process  ",  accept_proc_,name.  " at  node  ", 
accepT  node_narae,  "has  been  awakened  upon"); 
call  write_list_T"  receipt  of  a message  in  message  group", 


return- 


end: 


urn  ncmicy 


/* 


PROCESS  OBPL  PASS 


entry( p_obpl_passref ) ; 


6/24/76  •/ 


'/*  This“prbcedure  will  allow  a partially  expanded  OBPL  to  be  "received"  by  a 

as  much  as  possible  within  that  node  ■/ 


process  obpl_pass: 

This  procedure 

node  and  then  be  expanded  . . . . 

/*  Get  the  location  of  the  OBPL  entity  that  has  been  "passed"  between  nodes. 

We  need  not  check  "eos"  because  we  know  the  desired  entity  exists.  ■/ 
call  f i nd_f i rs t_( obp 1 re f , "obpl_pa3s->obpl" , p.obpl^passref . eos) : 

/*  Get  the  name  of  the  node  receiving  the  control  message.  */ 

rev  node_name  = extraetjp  obpl_passref,  "obpl_pass.dest_node_name") : 

/*  Remove  the  OBPL  from  this  control  message  sc  that  we  can  send  the  expanded 
OBPL  in  another  control  message  if  necessary  •/ 
call  removejobplref , "obpl_pass->obpl") : 

/*  Expand  the  OBPL  as  much  as  possible  in  the  receiving  node  •/ 

call  exp_obpl(obplref , rcv„node_name) : 

return- 
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Procedure  RCVCM 


/«  PROCESS  RESOURCE  GRANT  6/15/76  V 

prooess_res_grant : entry(  p_res_grantref) ; 

/*  This  procedure  will  wake  up  a process  and  give  it  access  to  a resource  as 
specified  by  the  remote  resource  grant  control  message  pointed  to  by 
"p  res_grai'itref"  V 

/*  Get  the  names  of  the  prooees,  resource  and  nodes  involved  »/ 
process  name  * extraot_(p  res_grantref,  "rea_grant.proc_.name") ; 
proc_nodc_name  * extract_Tp_rea_grantref,  "res_grant.proc_node_name"); 
dbo_name  s extract  ( p_i'es_grantre f , "res. .grant. res  name*); 


dbo  node  name  * extract?  p_res_grantref , ^*res^grant.res_node_name"); 

/"  Find  the  locations  of  the  entities  for  the  process,  resource  &nd  their  node 
tables  within  the  node  specified  by  "proc_node  name".  Note  that  we  need 
not  test  "eos"  because  we  know  the  names  placed  in  the  control  message 
represent  existing  entities.  •/ 

eos  a find  entity_loo(proc_noderef , "sys->node",  SYS_REF,  proc_node_name, 

iiod^  • niM^ ) * 

eos  a find_entity  loofproc  tableref.  "node->node_table",  proc_noderef , 
pruc  nbde_nane , "node  table . name" ) ; 

eos  a find  entTty_loe( procref , "node->proeess" , proe_tableref , process_name, 
"process. name"); 

eos  a find_entity_loc(dbo  tableref.  "node->node._table" , proc_noderef , 
dbo  node name.  *node_tabie.name*); 
eos  a find_entity_Toc( dboref,  "node->dbo",  dbo_tableref , dbo_name, 

"dbo.njuee") ; 

/•  Unblock  the  pi’oeess  •/ 

call  removefprocref,  "node/dbo/mg->procctis"); 

call  insert_( procref,  "node/dbo/mg->process" , "first",  proc  tableref): 

/•  Give  the  process  exclusive  or  shared  access  to  the  dbo,  depending  upon  the 
type  of  access  that  was  requested.  */ 
if  extract  (prooref,  "process. aeoess„type")  * "exclusive" 
then  do: 

/•  Grant  the  process  exclusive  control  of  the  database  object  */ 
call  insert  {dboref,  "prooess->dbo",  "first",  procref); 
call  write  list  (process  name,  "at  node",  proc_node_name , 

Tnas  beun  granted  exclusive  use  of"); 
call  write_list_(-  ",  dbo_name,  "at  node",  dbo_node_name) : 

return; 
end; 

else  do; 

/*  Grant  the  process  shared  access  to  the  database  object  */ 
call  do^dbo  8^_asmt(sh_asmtref); 

call  insert  Tsh_asmt ref , "dbo->dbo_sh_asmc",  "first",  dboref); 
call  insert  (sh_asmtref,  "process- >dbo_sh_asmt",  "first",  procref): 


call  write  Tist(process_name,  "at  node",  p 
"has  Deen  granted  shared  access  t 


roc_node_name , 


call  write_list_{" 

return; 

end, 


ouai  ou  auuvoc  vs/  / « 

",  dbo_name,  "at  node",  dbo_node_nan>e) ; 


j»**$>. n e^ytfjp  u«*teg£rtt»<«q?  fy?'  J~ ^*W^fc»ftr*3V^:R*1h-,  ^W^.'?^5^°-7S-'*^K  f?«-  — it>h— ^ ... 
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Procedure  RCV_CM 


/» 


PROCESS  RESOURCE  RELEASE 


6/15/76  •/ 


process_res_rel:  entry(p_res_relref ) ; 

/•  This  procedure  will  release  a resource  from  ocntrol  by  a remote  process, 
as  specified  in  the  resource  release  oontrol  message.  If  possible, 
additional  processes  will  be  removed  from  the  queue  for  the  database 
object  and  will  be  granted  access  to  the  database  object  */ 

/•  Get  the  names  of  the  process,  resource  and  nodes  involved  */ 
process  name  = cxtract_(p_res_rslrsf , "res_rel . relDro^naae* ) ; 
proc_noae_name  « extract_Tp_rea_relref,  "re8L_rel.rel_pnodp_n&me") : 
dbo_name  * extract_(p_res relrer,  * 


dbo_name  * extract  ip_res  relrer,  Kres_rei.aeat_dbo  name"; ; 
dbo  node  name  * extract_(p_res_relref , "res  rel.dest_node_naae") ; 
/•  Find  the  locations  of  the  entities  for  the  process,  resource  a 


node  tables  within  the  node  specified  by  "dbo  nodename 


and  their 
Note  that  we 


do  not  test  "eos"  because  we  know  the  names  pTacedin  the  resource  release 
oontrol  message  represent  existing  entities.  •/ 
eos  = find_entity_lo<Hdbo_noderef , "sys->node",  SYS_REF,  dbo_node_jname , 
^node.name"); 

* find_entity_loc(dbo  tableref.  "node->node_table" , dboynoderef, 
dbo  node  name,  "node  table. name"); 
s find  entity_Xoe( dboref , "node->dbo",  dbo_tableref , dbo_name, 

"dbo.nume") : 

s find_entity_loc(procL.tableref . "node->node_table" , dbo_noderef, 
proo  node_name,  "node  table. name"); 
find_entity_loc(procref , "node->process" , proc_tableref , 


eos 


eos 


eos  s 


eos  * 


process  name, 
e_list  (dbo_na 
e list_(" 


"process. name"; : 

name,  "at  node",  dbo_node_name,  "has  been  released 


by"); 


call  write _______  , _ _ 

rail  write _list_("  ",  prooeas_name,  "at  node",  proc  node_name); 

/*  Check  if  the  process  had  exclusive  control  of  the  database  object  •/ 
if  inserted_(dboref,  "prooesa->dbo") 
then  do; 

/*  Release  the  database  object  and  then  grant  at  least  one  other 
process  aooeas  to  the  database  object  if  any  processes  are 
queued  for  it  •/ 

call  remove  (dboref,  "process->dbo"); 
if  empty_( dboref,  "node/dbo/mg->prooess" ) 

then  call  rem_proo_from._queue( dboref,  dbo_tableref ) ; 
return; 
end; 

else  do; 

/•  Release  the  database  object  from  this  shared  assignment,  and  if 
there  are  no  other  processes  currently  having  shared  access  to 
the  database  object  we  can  grant  another  process  access  to  the 
database  object  if  any  are  queued  for  it  */ 
call  find_first_intersectlon..(8h_asratref . "process->dbo_sh_asmt" , 
procref,  "dbo~>dbo_ah_asmt" , dboref.  eos); 
call  delete_entity  (ah  asatref,  "dbo  ah_asmt"); 
if  member_coupt_( dboref , "dbo-odbo  sTLaamt")  s 0 

then  if  empty_(dboref,  "node/dbo/mg->process") 

then  call  renL_proc_from_queue(dboref , dbo_tableref); 

return; 

end; 
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/»  PROCESS  RESOURCE  REQUEST  6/15/76  */ 

prooes8_res_req : entry( p_rea_reqref ) ; 

/•  This  procedure  will  process  a request  for  a resource  from  a remote 

frocess,  as  specified  in  the  resource  request  control  message.  If 
he  resource  can  be  assigned,  it  will  be  and  a control  message  will 
be  generated  to  that  effect.  Otherwise  the  process  will  remain  blocked 
until  the  resource  beoomes  available.  "/ 

/»  Get  the  names  of  the  process,  resource  and  nodes  involved  */ 
process  name  a extract_( p_res_req ref , "res__req . req_proc_name" ) : 
proe_node_name  a extract_Tp_res_reqref,  "res_req . req_noae  naue" ) ; 
dbo_name  a extract  ( p_rea„reqref , "res„req.dest_dbo  name"); 
dbo_node_name  a extract  (pres_reqref,  "res  req.dest_node_name"); 

/"  Find  the  locations  of  the  entities  for  tne  process,  resource  and  their 


!_ node  name  3 extract  (pres_reqref,  "res  req.dest_node_name"); 

Find  the  locations  of  the  entities  for  tne  process,  resource  and  their 
respective  node  tables  within  the  node  specified  by  "dbo__node_name".  If 
the  node  is  unaware  of  the  existence  of  the  process,  create  a local  entit 


the  node  is  unaware  of  the  existence  of  the  process,  create  a local  entity 
for  that  process,  e do  not  have  to  test  eos  beoause  we  know  the  entities 
for  the  node  tables  and  the  resource  exist  because  the  names  were  placed 
in  the  resource  request  control  message  */ 
eos  = find  entityJLoc(dbo_noderef , "sys->node",  SYS_RBF,  dbo_node_name, 

"node. name" 1 ; 

eos  = find_entity_JLoc(dbo  tableref.  "node->node_table" , dbo_noderef, 
abo_node  name . "node  table . name" ) ; 
eos  s find  an tityJLoc( door ef,  "node->dbo",  dbo_tableref , dbo_name, 

"dbo.name"): 

eos  s f ind_entity_loc( proc  tableref . "node->node_tablo" , dbo_noderef, 
proc_noae  name , "node  table. name"); 

if  find_entity_loc( procref,  "noae->proceaa" , proe_tableref , process_name , 
"process. name") 
then  do; 

/•  Create  a "local"  entity  for  the  process,  since  one  does  not 
already  exist  •/ 

call  dcl_prooess(procref , process_name) ; 

call  insert  (procref,  "node->process",  "first",  proc  tableref); 
call  insert_( procref , "node/dbo/mg->process",  "first", 
proc_tableref) ; 

end: 

/•  Determine  what  type  of  access  is  desired  "/ 
access_type  s extract_(p_res„reqref,  "res_req.acceas_type") ; 

/*  Check  if  the  database  object  might  bg  available  for  assignment  */ 
if  inserted_(dboref , "process->dbow)  ! empty_(dboref , "node/dbo/mg->process") 
then  do:  /"Block  the  process  if  the  database  object  has  been 


then  do:  /"Block  the  process  if  the  database  object  has  been 

assigned  to  another  process  for  exclusive  use  or 
if  other  processes  are  currently  queued  for  the 
database  obje<^  */ 

call  alter_(procref,  "prov ss.access_type",  access. type) ; 
call  remove!  procref,  "node/dbo/mg->process") : 
call  insert  (procref,  "node/dbo/mg->process",  "last",  dboref): 
call  write_list  ("Resource  not  available,  process  remains  blocked"); 
call  initiate_obpl(proc_node_name,  process,  name,  dbo_node_name, 
dbo_name,  "dbo"): 

return; 

end: 

/*  Check  if  the  request  is  for  shared  access  */ 
if  access_type  = "shared" 

then  do;  /"Give  the  process  shared  access  to  the  desired 

database  object  */ 
call  dcl_dbo  sh_asmt(sh_asmtref) ; 

call  insert  Tsh_asmtref.  "dbo->dbo _sh_asmt",  "first",  dboref);, 
call  insert  (sh_asmtref,  "process->dbo_sh_asmt" , "first",  procref): 
call  write  Tist_(process_name,  "at  node",  proc_node_name, 

"is  granted  shared  access  to"): 

call  write._list_( " ",  dbo_name,  "at  node",  dbo_node_naoe) : 

call  dcl_renLres_grant(dbo_node„name,  dbo_name,  proc_node_name , 
process  name,  cont_msg_numb) : 
call  write  list_ ("Control  message  number",  cont_msg_numb, 

"sent  f;  jm",  dbo_node_name.  "to".  proc_node_name) 
call  write_list_("  representing  this  allocation")1 
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return: 

end? 

/•The  next  if  statement  will  be  executed  if  the  request  is  for 
exclusive  use  of  the  database  object  */ 

/•  Check  if  any  prooess  has  shared  access  to  the  desired  database  object  •/ 
if  empty  (dboref,  "dbo->dbo  3h_asat") 

then  do:  /•Queue  the  prooess  for  exclusive  use  of  the  database 

object  because  at  least  one  other  process  currently 
has  shared  aeoess  to  the  database  object.  */ 
call  alter_(procref.  "process . access_type" , "exclusive") : 
call  removal  prooref,  "node/dbo/mg->proeeasfl); 
call  insert_(proeref , "node/dbo/ag->process" , "last",  dboref); 
call  write  Iist._( "Resource  Is  not  currently  available  for", 
"exclusive  use,  process",  prooess^paae) ; 
call  wrlte_list_("  at  node",  proc_node_name , 

"remains  blocked"); 

call  initiate_obpl(proo_node_naae,  prcoesa„name,  dbo_jnode_name, 
dbo_name,  "dbo"); 

return: 

end; 

else  do:  /vGrant  the  prooess  exclusive  use  of  the  desired 

database  object.  •/ 

call  insert  (dboref,  "prooess->dbo",  "first",  proeref); 
call  write  Iist_(process_name,  "at  node",  proc_node_naoe, 

"is  granted  exclusive  use  of"): 

call  write_liat_("  ",  dbo.naae,  "at  node",  dbo_node_naae) : 

call  dcl_rem_  res_grant(dbo_node_naae,  dbo._name,  proc_node_name, 
process  name,  cont_jnsg_numb) ; 
call  write  llst_("Control  message  number",  contjnsgnuab, 

"sent  from",  dbo_node_jname,  "to".  proc_node_name) ; 
call  write_list_("  representing  this  allocation"); 

return? 
end: 

end  RCV_CM: 
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OBPL:  procedure; 

/•  This  procedure  is  a collection  of  subroutines  which  act  on 
an  OBPL  and  check  for  deadlock. 

The  following  support  routines  are  included: 

CHECK  FOR  DEADLOCK 
COPT  OBPL 
EXPAND  OBPL 

OBPL  ADD  RESOURCE  •/ 


del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

^include 

^include 


eos 

first_procref 

mesaage_numb 

mgref 

ndBLi>roc_ownerref 

new  obplref 

obpX_proc_name 

obpl_prop_node_name 

obplwproo_node_tableref 

obpl_procref 

oldjproo  entryref 

op_conrer 

operator_name 

opref 

p_oopyref 

p_eos 

p_ndaproe_ownerref 

p_obplref 

p_process  name 

p_proe_node_name 

p_rcv_node_na«e 

proc_entryref 

process  name 

proc_node_name 

procref 

proc_tableref 

rcv_noderef 

res_name 

rea_pode_name 

res_node_tableref 

rearef 

res_type 

ah  aamtref 

write_JLiat_ 

DDM_aerv  routines: 

ADT_priniitives; 


bit ( 1 ) : , v 

fixed  bin(17) 
fixed  bin 
fixed  bin 
fixed  bin 
fixe< 
char 
ehar 

fixed  bin 
fixed  bin 
fixed  bin 
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sd  bln 

Mi 


17 

17 

17 


17 

:» 

!l7 


n(l7); 


fixed  bin 
ohar  7 1 2 ) ; 
fixed  bin(17) ; 
fixed  bint  17); 
bit  ( 1 )j 
fixed 
fixed  b; 
char  M2 
ohart 12 
chart  12, 
fixed 
chart 
chart 

fixed  bin(17) 
fixed  bin(17J 
fixed 
chart 
chart 

fixed  bint  17): 
fixed  bint  17); 
char(7);  . „ 

fixed  bint  17); 
entry  options(variafcle) ; 
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/«  CHECK  FOR  DEADLOCK 

check  for_deadloek:  entr 
/•  This  procedure  will  cl 
and  located  in  the  node 


6/25/76  •/ 

peos); 
ame" 

_ _ _ as  an 

entry  in  the  OBPL  pointed’ to  by  "p_obplref".  If  no  such  entry  exists, 
then  one  will  be  created  and  "peos"  will  be  set  to  "1"b,  indicating  that 
there  is  no  deadlock.  If  an  entry  already  exists  for  the  process,  we 
have  a deadlock  ar.d  a message  will  be  printed  giving  the  processes 
involved  and  "p_eos"  will  be  set  to  "0"d  indicating  a deadlock  has  been 
detected.  */ 

/*  Get  the  location  of  the  first  proe_entry  in  the  OBPL  */ 

call  find_.first_(proe_entryref.  "obpl->proe_entry".  p_obplref.  p_eos) : 

/•  For  each  proc_entry  in  the  OBPL,  check  if  it  matches  the  given  process. 
Note  that  if  we  detect  a deadlock,  we  will  return  from  inside  the  loop 
and  p_eos  will  be  0.  If  no  deadlock  is  deteoted  we  will  exit  the  loop 
before  Returning  and  p_eos  will  be  1 , as  desired.  */ 
do  while  ( p_eos); 

/*  If  we  have  a match  with  "p_jproees3_name"  and  a proc_entry,  we  must 
then  check  if  the  node  name  attribute  matches  "p jproc_node_name"  */ 
if  p_process_name  s extract_(proc_entryref,  "proc_entry.proceas_name") 
then  if  p t>roc_node  .name  a extraet_(proc_entryref, 

^proo_entry . node_name" ) 
then  do; 

/*  A deadlock  has  been  detected,  list  all  the  processes 
involved  and  return.  •/ 

call  write  list  ("A  deadlock  has  been  detected.", 

"The  following  processes  are  involved:"); 
eos  = "0"b; 
do  while  ( eos) : 

processjname  s extract_(proc_entryref, 

"pro<L.entry . process_name" ) ; 
proc_node_name  = extract  (proc_entryref, 

"proc_entry .noae_nam»" ) ; 

call  write  llst_("  ",  process_name, 

"at  node  ",  proc_node_name) ; 
call  find_prior_(proc_entryref , "obpl->proc_entry" , 
eos) ; 

end: 

call  write_list_("  End  of  deadlock  list"): 

return; 

end; 

/*  Get  the  next  proc_entry  in  the  OBPL  •/ 

call  find_next_(proc_entryref,  "obpl->proc_entry" , p_eos): 

end- 

/*  No  deadlock  has  been  detected,  so  create  a new  proc_entry  and  have  it 
inserted  into  the  OBPL  */ 

call  dcl_proc_entry(p_obplref , p_proc_node_name , p_process_name) : 
return: 
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/•  COPY  OBPL  6/25/76  «/ 

eopv  obpl : entry (p_copyref,  p_obplref): 

/•  Tni*  procedure  will  copy  the  OBPL  pointed  to  by  "p_obplref"  and  return 
a pointer  to  the  copy  via  "p_copyref".  The  order  of  the  OBPL  entries, 
and  their  attribute  values  in  the  copy  will  be  identical  to  those  in 
the  original.  •/ 

/•  Get  the  attribute  values  (resource  information)  from  the  OBPL  entity 
pointed  to  by  "p  obplref".  */ 
res_name  s extract_Tp_obplref,  "obpl. res  name"): 
res_node_name  * extract! p_obplref , "obpl.res_node_name"); 
res  type  = extraot_( p oDplref , "obpl.res_type") : 

/•  create  an  OBFL  entity  with  the  above  attribute  values  •/ 
call  del_obpl(p_eopyref.  res_node_naae , res_name,  res_type): 
message  numb  * extraet_(p  obplref,  "obpl.msg_nurab") : 
call  aiter_(p_copyref,  "obpl.msgnumb",  measage_nuob) ; 

/•  Get  the  last  entry  in  the  OBpU  pointed  to  by  "p_obplref"  */ 
call  findjlast  (oldj>roc_entryref,  "obpl->proc_entry" , p_obplref,  eos): 

/•  Copy  each  OBPL  entry  ■/ 
do  while  (eos); 

/-  Get  the  attribute  values  of  the  proe_entry  pointed  to  by 
"oldl_proc_entryref"  •/ 

process  name  * extract_(old_prce_entryref , "proc_entry.process_narae"): 
proc_node  name  * extraot_( oTd_proc_entryref . "proc_entry. node name"): 
/•  Create  a new  proc_entry  with  the  above  attribute  values  ana 
insert  it  into  the  new  ecpv  of  the  OBPL.  •/ 
call  dclprocL.entry(p_oopyref,  proo_node_name,  procesajname) ; 

/»  See  if  there  are  any  more  proc  entries  to  be  copied  »/ 
call  find_prior .(old_proc_entryref,  "obDl->proe_entry" , eos); 
end: 
return: 
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/•  EXPAND  OBPL  . 6/2*1/76  */ 

exp  obpl:  entry (p_obplref,  D_rcv_node_name) : 

/•  This  procedure  will  expand  the  OBPL  pointed  to  by  "p_obplref".  It  will 
be  expanded  as  much  as  poxxible  using  the  information  available  to  the 
node  speoified  by  " p r o v_nodename " •/ 

/•  Get  the  fully  qualified  name  Tresouree  name  plus  the  name  of  the  node 
in  which  it  resides)  of  the  resource  which  is  controlled  by  or  being 
waited  for  by  the  last  process  to  be  added  to  the  OBPL.  (Note  that  we 
add  processes  to  the  OBPL  by  inserting  them  at  the  beginning  of  the  set  •/ 
res_name  a extract_(p_obolref , "obpl.res.name") ; 
res  node  name  * extract_([p_obplref , "obpi.reajnode  name"): 

/•  (Tet  the  type  of  the  resource  ("message"  or  "dbo"  or  "op_msg")  */ 
res_type  a extract_(p_obplref , "obpl.res_type"); 
if  res  type  a "message" 
then  do* 

/*  The  resource  type  is  a message,  therefore  we  know  the  process 
that  can  send  tne  desired  message  is  in  the  node  that  is 
expanding  the  OBPL,  We  will  act  accordingly.  */ 

/*  Get  the  location  of  the  entity  for  the  message  group  from  which 
a message  is  desired.  We  need  not  test  "eos"  because  we  know 
the  entity  exists.  */ 

eos  = find  entity_loc(mgref,  "sys-Omessage",  SYS_REF,  res_name, 
^message.name"): 

/*  Get  the  number  (within  the  message  group)  of  the  message 
that  is  desired.  */ 

message  numb  a extract_(p_obplref , "obpl.msg.  numb") ; 

/•  If  tKis  number  is  less  than  or  equal  to  the  number  of  messages 
sent  in  this  message  group,  then  there  is  no  deadlock.  •/ 
if  (messagejnumb  > extract_(mgref , "message.number_sent")) 
then  return: 

/•  Find  the  process  that  can  send  the  desired  message  •/ 
call  find_owner  (procref,  "send_proc->message",  mgref): 

/*  Find  out  if  the  process  is  active,  tlf  it  is  active  there 
is  no  deadlock.)  •/ 

call  flnd_owner_(ndni_nroc_ownerref , "node/dbo/mg->process" , 
procref) : 

If  entity_class_narae_(ndnL.proc_ownerref)  = "node_table" 
then  return: 

/*  Get  the  process  name  and  check  for  deadlock  */ 
process_name  = extract_( procref,  "process. name") ; 
call  check_for_deadlock(p_obplref,  res_node_name , process_name, 
eos) ; 

/•  If  eos  s 0 then  a deadlock  has  been  detected  and  we  are  done  */ 
if  (eos) 

then  return: 

/•  Add  the  resource  that  the  process  is  waiting  for  to  the  OBPL  */ 
call  obpl_add_resource(p_obplref , ndm_proo_ownerref , 

P-J'cv_node  name,  eos): 

/•  If  eos  = 1 then  tne  resource  the  process  is  waiting  for  is  in 
the  same  node  as  the  process,  so  we  can  continue  to  expand 
the  OBPL.  •/ 
if  eos 

then  call  exp_obpl(p_obplref , p..rcv_node_name) : 
return* 
end: 

if  res_type  = "op_msg" 
then  do* 

/*  The  resource  type  in  an  operator  message,  therefore  we  know 
the  last  process  to  be  added  to  the  OBPL  is  waiting  for  a 
message  from  an  operator  at  the  same  node.  We  will  act 
accordingly.  */ 

/*  Get  the  location  of  the  entity  for  the  onerator  connection 
over  which  a message  is  desired  */ 
eos  = f ind,. entity  Joe(oo__eonref . "svs->op_con"  , SY^_REF, 
res_name,  "op  con. name"): 

/*  Get  the  location  and  name  of  the  operator  wno  can  send  the 
desired  message  */ 
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call  fin<L.owner_(  opref.  "operator->op_con",  op  conref): 
operator_naae  s extract_( opref,  "operator. name") : 

/*  Check  if  the  operator  is  already  in  the  OBPL  list  */ 
call  eheok_for_deadlock(p.  obplref,  res_node_name , 
operator_name,  eos); 

/*  If  eos  s 0 then  a deadlock  has  been  detected  and  we  are  done  V 
if  (eos) 

then  return: 

/•  Queue  the  OBPL  and  request  status  information  from  the 
operator  •/ 

call  insert  (p  obplref,  "operator->obpl",  "first",  opref); 
call  vrite_.Tiat_("An  OBPL  has  been  queued  waiting  for  a status", 
"report  from  operator",  operator_name) ; 
call  write  list  ("  at  node",  res  node_name, 

"The  involved  operator  connection  is",  res_name): 

return; 

end: 

/*  If  the  next  section  is  exeouted,  a database  object  is  controlled  by  or 
is  being  waited  for  by  the  last  process  to  be  added  to  the  OBPL  */ 

/*  Get  the  name  and  location  of  the  last  process  to  be  added  to  the  OBPL  */ 
call  find  first_(obpl_procref . "obpl->proo_entry" , p_obplref,  ec. ' ; 
obpl_jproc_name  « extract  (obplprooref,  "proe  entry. process  name"); 
obpl_proc_node  name  * extract_Tobpl_proeref , "proc  entry. noae_name"): 

/*  Get  the  entity  locations  for  the  database  object  and  its  node  t^ble,  and 
the  process  and  its  node  table  within  the  node  specified  by 
"p_rcv  node  name".  We  need  not  test  "eos"  in  most  cases  because  we 
know  the  entities  exist  */ 

eos  = find  entity_loo(rcv_noderef , "sys->node",  SIS_hEF,  o_rcv_node_name, 
Tnode.name") ; 

eos  s find_entity_loc(obpl  proo_node_tableref,  "node->node_table" , 
rev  noderef . obpl_proo_jnode_name,  "node_table.name") : 
eos  = find_entity_loc(res  node__tableref,  "node->node_tabls" , rov_noderef, 
res  node  name . "node_table . name" ) ; 

eos  s find_entity_Toc(oopl  orocref,  "node->process",  obpl_proc_node_tableref , 
obpl_proc_name , "prooess.narae") ; 

/•  We  must  test  "eos"  to  see  if  the  node  containing  the  resource  is  aware 
of  the  existence  of  the  most  recently  inserted  process  in  the  OBPL.  If 
it  is  not,  we  have  no  deadlock  at  this  time,  so  we  can  return  */' 
if  eos 

then  return: 

eos  = find_entity_loc(  resref , "node->dbo",  rea_node_tableref , 
res  name,  "dbo.name"); 

/•  Cheek  if  the  resource  is  in  the  node  that  is  expanding  the  OBPL  */ 
if  res  node_name  = p_rcv_node_narae 
then  do; 

/*  Verify  that  the  process  specified  by  "obpl_proc  name"  is  still 
waiting  for  tne  resource  specified  by  "res  name"  •/ 
call  find_owner_(ndni_proc_ownerref > "node/dbo7mg->process" , 
obpi_procrer);. 

if  resref  *=  ndm_proc_ownerref 
then  return’ 

/*  We  oust  now  add  an  entry  to  the  OBPL  for  the  process 
that  controls  the  resource  specified  by  "res.. name", 
provided  that  the  process  is  not  already  in  ti e 
OBPL.  If  there  are  n processes  that  have  shared 
access  to  the  database  object,  then  we  must  create 
n copies  of  the  OBPL  and  use  a different  copy 
for  each  reader  */ 
if  inserted_(resref , "prooess->dbo") 
then  Jo: 

/*  The  database  object  is  held  for  exclusive 
use.  Find  the  controlling  process  and 
check  for  deadlock.  */ 
call  find_ owner  (prooref,  "r>rooess~>dho" , 
resreT) : 

proces:i_name  ? extrgct_(Drecref , "process. name" ) 1 
call  find,  owner  (proc.tableref ,,f!ode->prooessn  . 

1 <■* 
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<R\f- 


tableref, 


prooref): 

proo  node  name  * extraot_. 

"noda^f able. nano 

call  find_owner  (ndm  proc_ownerref, 

"node7abo/5g->proee8s" , prooref); 

/*  If  the  process  is  active  and  it  is  at  the 
same  node  as  the  resource,  then  we  have 
no  deadlock.  •/  , . 

if  entity_class name  (ndm_proc_ownerref) 

s "noae_tableM  & proc„node_name 
= res_node_name 
then  return; 

call  checkwfor_deadlock(p_obplref , 

proc_nodejname , procesa_name,  eos); 

/•  If  eos  a 0,  than  a deadlock  has  been 
detected  and  we  are  done  */ 
if  (eos) 

then  return; 

if  proc_node_name  * rea_node_name 
then  do; 

/*  The  process  is  in  the  same  node  as 
the  database  object,  so  we  can 
continue  to  expand  the  OBPL  •/ 

/•  Add  to  the  OBPL  the  resouroe  that  the  process 
is  waiting  for  •/ 
call  obpl_adaLresource(p_obplref , 
ndBLpnoo  owner re f , 
p_rev  node  nam**,  eos); 

/•If  eos  » 1 , Yhen  the  resouroe  that  was  added 
to  the  OBPL  is  in  the  same  node  as  the 

frocess  that  is  waiting  for  it,  so  we  can 
urther  expand  the  OBPL  •/ 
if  eos 

then  call  8xp_obpl(p_obplref , 
p_rcv_node_name) : 

return: 

end; 

else  do: 

/•  Send  the  OBPL  to  the  node  specified 
by  "proc_node_name"  V 
call  dcl_obpl_cont_msg(p_obplref , 

p roc_node_name , p_rev_node_narae ) ; 

return: 

end; 


end; 

/•  If  the  following  code  is  executed,  the  database  object 
has  n readers.  We  need  to  make  n-1  additional  copies 
of  the  OBPL.  Each  time  we  make  a copy  of  the  OBPL, 
we  expand  that  copy  as  much  as  possible  for  the  given 
node  and  the  process  that  we  are  associating  with 
this  copy  •/ 

/•  find  a process  that  has  shared  access  bo  the 
database  object  •/ 

call  find_first  (sh_asmtref,  "dbo->dbo_sh_asmt" , 
resrer.  eos;: 

call  find  owner _(first_procref,  "process->dbo_sh_asmt" , 
sh  asmtref); 

/•  We  will  check  for  deadlock  involving  the  OBPL  end  the 
process  pointed  tu  by  M first  Drocref"  ai'ter  we  .-.heck 
for  deadlock  with  all  the  other  readers  of  t-.e 
database  object.  We  will  tenerefore  use  the  “original" 
QPPL  (rather  than  a copy)  for  this  check  */ 

call  find  next  (sh  asmtref,  Mdbo->dbo_nh_as®t" , eos): 

do  while  X eosT; 

/•  Find  the  process  tnat  has  the  shared  access 
represented  by  the  dbc_sh„?smt  entity  pointed 
tc  by  "sn  ..asmtref"  */ 


Appendix  II 


Procedure  OBPL 


call  find_owner_( procref , "process->dbo_sh_asmt"t 
sh_asmtref ) ; 

process  name  = extract_( procref,  "process. name” ) ; 

/*  Get  the  name  of  the  node  in  whion  the  process 
resides  •/ 

call  find_owner_(proe_tableref , "node->process" , 
procref) ; 

proc_node_name  s extract_(proc_tableref , 

"node_table . name" ) : 

/•If  the  process  is  not  active  or  if  it  is  at  a node 
different  from  the  node  in  which  the  resource 
resides,  then  we  must  cheek  for  deadlock.  •/ 
call  find_owner _(ndmproe_ownerref , 

"node/dbo/ig- >process" , procref) : 
if  entity_5lass_name_Tndnuproc_ownerref) 

A*  "node_table"j  ( proc_jiode_r.aae 
* res  node_name) 
then  do: 

/*  Copy  the  OBPL  and  check  for  deadlock  */ 
oall  copy  obpl( new  obplref,  p obplref): 
call  eheole.for_deaalock{ new_obplref , 

proc  node_name,  process_naae . eos): 

/•if  eos  * 1 then  we  must  either  continue 
to  expand  the  list  or  send  it  to 
another  node  •/ 
if  eos 

then  if  proc_node_name  a res_node_name 
then  do: 

/•  Add  to  the  OBPL  the  resource  that 
the  prooess  is  waiting  for  •/ 
cal)  obpl„add_resource( 
new_obplref , 
ndnLproc  ownerref , 
P_rcv_noae_name , eos): 

/•  If  eos  = 1,  then  the  resource  that 
was  added  to  the  OBPL  is  in  the 
same  node  as  the  process  that,  is 
waiting  for  it,  so  we  can  further 
expand  the  OBPL  •/ 
if  eos 

then  call  exp_obpl( 

new_obplref , 

P_rcv_  node__nane ) • 

end: 

else  call  '1el_obpl_cont_rasg( 
new_obplref , 
proc_node_name, 
p rcv_node_name) ; 

end: 

/•  See  if  there  are  any  more  readers  of  the  database 
object  specified  by  "res_name"  •/ 
call  rind_next_(sh_asmtref , "dbo->dbo_sh_asrat" , eos): 

a **  • 

v»»w  • 

Find  the  process  name  and  the  node  in  which  it  resides 
for  the  process  pointed  to  by  "first_j>rocrt'f"  •/ 
process_naae  = extract  (first  procref,  "process. name"): 
call  rind_owner__(pr-ocJ:ablere?,  "node->process" , 
first_procref) : 

proc  node_name  = extracts proc_tableref , "node. table, name") : 

/*  If  the  process  is  at  the  same  node  a?  the  resource  and 
it  is  active,  we  need  not  check  for  deadlock.  */ 
call  find_.nwner_(^dm_proc_owr.erref , "node/dbo/mp-^roceys"  , 
first_prjcref ) • 

if  entity_class_naffie_{ndm_proc_.owrerref ) = "node. table" 

A proc_node„ name  = res_node_.name 
then  return' 

/•  Check  for  deadlock  and  the:  expand  *'he  OPPL.  <>r  send 
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it  to  another  node  */ 

call  cheok_for_deadlock(p_obplref , proc_node_name, 
process_tiame,  eos); 

if  eos 

then  if  proc_node_name  * res_node_name 
then  do: 

call  obpl_add_resource(  p_obplref , 

ndffliDroc_ownerref , p_rcy__node_name , 
eosT; 

if  eos 

then  call  exr_obpl(p_obplref, 

P_rcv_node_name) : 

end: 

else  call  dcl_obplweont.jnag(p_obplref , 

proc_node_natnd , p_rov_node„name ) ; 

return; 

end: 

/*  The  next  section  of  code  will  be  executed  if  the  resource  is  located 
in  a node  different  from  the  one  that  is  expanding  the  list  */ 

/*  First  check  if  the  process  is  active.  If  it  is  active,  we  are  done  */ 
call  find_owner_(ndnu&*'oc_ownerref,  Mnode/dbo/mg->process",  obpl_procref ) : 
if  entity_class_name_vndui_proc_ownerref)  * "node_tableB 
then  return* 

/*  Verify  that  the  prooess  specified  by  "obplwproc_name"  still  controls 
the  resource  specified  by  "res_name"  •/ 

/*  See  if  the  process  had  either  exclusive  or  shared  access  to 
the  database  object  specified  by  "res_name".  If  it  has  neither, 
we  can  return.  •/ 

if  (eopty_interaection  (obpl_prooref,  "proeess->dbo" , res_node_tableref , 
"node->dbo")T  4 (emptv  interseotion_(obpl_proeref 
*"process->dbc_sh_asmt" , resref,  "dbo->dbo_sh_asmt")) 
then  return: 

/*  Add  to  the  OBPL  the  resource  that  the  process  is  waiting  for  •/ 
call  obpl_add_resource(p_obplref , ndnt.proc_ownerref,  p_rov  node  name,  eos): 
/•If  eos  s 1,  then  the  resource  that  was  added  to  the  OBPL  is  In  the  same 
node  as  the  process  that  is  waiting  for  it,  so  we  can  further  expand 
the  OBPL  •/ 
if  eos 

then  call  exp_obpl(p_obplref , p_rcv_node_name) ; 
return* 
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/*  OBPL  ADD  RESOURCE  6/24/76  •/ 

obpl_ad<Lresource:  entry (p_obplref,  p_ndm_proc_ownerr ef , p_rcv_node_name , 
p„eos ) ; 

/*  This  procedure  will  be  passed  a pointer  to  a resource  that  the  most 
recently  inserted  process  in  an  OBPL  is  waiting  for.  The  procedure  will 
determine  the  type  of  resource  that  "p_ndm_proc!_ownerref"  points  to.  and 
will  insert  information  about  this  resource  into  the  OBPL  entity  pointed 
to  by  "p_obplref".  If  the  resouroe  is  in  the  rode  specified  by 
"p_rcv_node_naae" , then  p_eos  will  be  set  to  1.  otherwise  it  will  be  set 
to  0 and  the  OBPL  will  be  sent  to  the  node  that  contains  the  resource  */ 
if  entity_class_name_(p-ndBi_proc_ownerref ) = "dbo" 
then  do; 

/•  Get  the  database  object  name  and  get  the  name  of  the  node  in 
which  it  resides  */ 

res  name  = extract. (pjndnLjproc_ownerref,  "dbo. name"); 
call  find_owner_(res.jiode_tableref , "node->dbo" , 
P_jndm_j>roc_pwnerref ) ; 


res  node_name  a extraot  (res_node  tableref,  "node_table.name"); 

call  alter_(p_obplref , "obpl.res_type"f  "dbo"); 

end; 

if  entity„claas  name_(p_jidm_proe_ownerref)  a "message" 
then  do;  ~ 

/•  Get  the  message  group  name  and  the  name  of  the  node  from 
which  a message  should  be  coming  •/ 
s name  s extract 


res  name  s extr 
calT  findowner. 


Ld  be  coming  •/ 


■act_(p_jidni_proo_ownerref . "message. name" ) ; 
‘_(re3_node_tableref , "ini t_node->message" , 


p_ndm_proc_ownerref ) ; 

res  node  name  = extraet_(res_node tableref,  "node_table.name") ; 

/•  Get  tne  number  of  the  message  (within  the  message  group)  that 
is  desired  and  insert  this  into  the  OBPL  */ 
message  numb  = extract  (pndm_proc_ownerrcf,  "message. number_qd")+1 ; 
oall  alter_(p_obplref , "obpl.msg_numb",  nessage_numb) ; 
call  alter_(p_obplref , "obpl.res_type",  "message"); 
end; 

if  entity_class_name_(p_ndm__proc_ownerref)  = "op_con" 
then  do; 

/•  Get  the  name  of  t'ne  operator  connection  over  which  a message 
from  an  operator  is  desired  •/ 
res  name  = extract_(p_ndm_proc_ownerref , "op_con.name") : 

/•  The  resource  (operator  connection)  is  located  entirely  in 
one  node,  so  the  resource  node  name  is  the  same  as  that  of 
the  node  processing  the  OlPL  *7 
res  node_name  = p rcv_node_name; 
call  alter_(p_obplref , "obpl.res_type",  "op_msg"); 
end; 

/*  Put  the  resource  name  and  its  node  name  into  the  OBPL  */ 

call  alter (p_obplref,  "obpl.res_name",  res_name); 

call  alter  (p_obplref,  nobpl.res_node_name",  res  node_name); 

/•  Check  if  the  node  can  continue  to  expand  the  OBPL  or  if  it  must  send  the 
OBPL  to  another  node  */ 
if  res_node_name  = p rcv_node_name 
then  p_eos  s "1"b: 
else  do; 


return • 
end  OBPL; 


p_eos  s "0"p; 

call  dcl_obpl_cont_msg(p_obplref , res_node_name,  p_rcv_node„name) ; 
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$ 


Ff5L : procedure : 

/•  This  procedure  contains  (Subroutines  which  allow  processes 
to  release  resources  and  then  assigns  the  roleased  resouroe  to  a new 
process  if  possible.  The  following  user  visible  function  is  included: 

RELEASE  DATABASE  OBJECT 
The  following  support  routine  is  included: 

REHOVE  PROCESS  FROM  QUEUE  •/ 


del  eont_jnsg_numb 

del  dbo_name 

del  dbo_node_nane 

del  dboref 

del  dbo_tableref 

del  eos 

del  ndm_proc_ownerref 

del  ownerref 

del  p_dbo_name 

del  p_dbojnode_name 

del  p_dboref 

del  p_dbo_tableref 

del  pnoderef 

del  p_process  name 

del  p_proc_jnode_name 

del  process  name 

del  proc_noae_name 

del  procref 

del  ptableref 

del  res_rel_ref 

del  sec_node_name 

del  shasmtref 

del  tableref 

del  temp_name 

del  write_list_ 

^include  DDH._serv  routines; 

linolude  ADT_primTtives : 


fixed  bin; 
ohar(12); 
chart  12): 
fixed  binl 17 
fixed  binl 17 
bit(l); 
fixed  bin 
fixed  bin 
oharl* 


!)i 


i; 

mi 


binl 


chart*] 
fixed 
fixed  binl 
fixed  binl 
chart 


char 
char 

char. 

fixed  binl 17); 
fixed  binl 17); 
fixed  binl 17); 
eharl 12):  , 

fixed  binl 17 
fixed  binl 17] 
charl 12): 
entry  options (variable) ; 


'M 
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/“  RELEASE  DATABASE  OBJECT  6/2/76  •/ 

release_dbo:  rldbo:  ent ry ( p_proc_node_name , p_proeess_name , p_dbo_node_name, 
p_dbo_jjame) : 

/*  This  procedure  will  oause  uhe  process  specified  by  “p  oroceaa  name"  (at 
node  "p_proc_node  name")  to  release  its  control  over  the  database  object 
specified  by  "p_dbo i name"  and  located  at  the  node  specified  by 
"p_dbo _jiode_name"  «7 

/*  Verify  that  the  node  specified  by  "p  oroc  nodejname"  exists  */ 
if  find_entity_loc(pnoderef , "sys->node'r,  SYS_REF,  p _proe_node_name , 

"node. name"); 
then  do: 

call  write  list_( "Invalid  prooess  node  name.  ",  p_proc_node_name , 
"does  not  exist"); 

return; 

end: 

/*  Verify  that  the  process  specified  by  "p_jproeess_name"  exists  at  the  node 
specified  by  "p  broc  nodejiame"  */ 
eos  s find_entlty_Ioc(ptableref , "node->node  table",  pnoderef, 
p_proe_node_naae , "node_table . name") : 
if  find_enlity_loo( procref , "node->proeess",  ptableref,  p_process_name, 
"process. name") 
then  do: 

call  write__list_( "Invalid  process  name.",  p _process_name,  "at  node", 
p_proe_.rode_name,  "does  not  exist"); 

return; 

end: 

/•  Verify  that  tha  node  specified  by  "p  dbo_node  name"  exists  •/ 
if  find_entity_loc(dbo_t»hleref , "node-Tnode  table",  pnoderef, 

P_dbo_node_nairie , "node_table . name  "7 
then  do: 

call  write_list_( "Invalid  database  pbjept  node  name.  ", 

'•  / > 


return; 
end 


p_dbo_node_name , "does  not  exist. 


cuu « 

/*  Verify  that  the  database  object  specified  by  "p_dbo_name"  exists  at  the 
node  specified  by  "p_dbo_node_name"  and  that  the  Droceas  sDeeifled  bv 
"p_process_name"  has  access  to  It.  */ 

/•  Veri 


node  specified  by  "p_dbo_node_name"  and  that  the  process  specified  by 
rocess_name"  has  access  to  It.  */ 

fy  that  the  node  containing  the  process  is  aware  of  the  existence  of 
‘ect  */ 

dboref,  "node->dbor,  dbo_tableref , p_dbo_name,  "dbo.name") 

Process",  p process_name, 

_ e,  "does  not  have"); 
access  to",  p_dbo_name,  "at  node", 


the  database  object  */ 
if  find_entity_loc( 
then  do: 

call  write  list_( "Invalid  release 


Tat  node",  p_proe_node_name,  "does  no!  have"); 
>_list_("  ‘ “ " 


call  write 

P_dbo„node_narae ) 

return; 

end: 

/*  Verify  that  the  process  has  access  to  the  database  object  */ 
if  find_entity_loc( dboref , "process->dbo",  procref.  p„dbo_name,  "dbo.name"! 
& empty  intersection_(procref,  "process->dbo_sh_asmt",  dboref, 


"dbo->dEo_sh_asmt " ) 
then  do; 

/*»<a  1 1 fa  H mf  ^BTnwel  4 ^ 


DwiAAA  M tvfl 


• I » wvwwii  J VWWklU  liuiuv  , 

"at  node",  p_proo__node_name . "does  not  have"): 
call  write_list_("  access  to",  p_dbo_naroe,  "at  node", 

p_dbo_node_name) : 

return: 

end; 

/*'  Verify  that  the  process  is  active  */ 

call  find_owner_(ndra_proc_ownerref , wnode/dbo/mg->process" , procref); 

"node  table" 


Process  ",  p_process_name, 


i f ent ity_class_name_(ndaLproc_ownerref ) 
then  do: 

call  write list_("Invalid  release,  rrocess  pei 

Tat  node",  p_proc_node_narae,  "Is  not  active"): 

return: 

end: 

/*  Check  if  the  database  object  is  at  a node  different  iron  the  one  that 
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if 


/* 

/• 

if 


contains  the  process  */ 
p __proc_node_name  = p_d  bo_node_name 
then  do: 

/*  Release  the  resource  and  send  a resource  release  oontrol  message 
to  the  node  which  contains  the  database  object  •/ 

/•  Check  if  there  are  no  more  "local"  processes  queued  for  the 
specified  remote  database  object  •/ 
if  empty_(dboref , "node/dbo/mg->process") 
then  do; 

/•  If  the  process  had  exclusive  control  of  the  database 
object  or  if  no  other  local  process  had  shared  access 
to  the  database  object,  then  we  can  delete  all  local 
information  about  the  remote  database  object, 
otherwise  just  "release"  the  shared  access  of  the 
process  to  the  database  object  */ 
if  inserted_( dboref , "crocess->dbo") 

i member_oount (dboref,  "dbo->dbo  sh_asmt")  < 2 
then  call  delete_entity_(dboref , "dbo"7; 
else  do; 

/*  Find  the  entity  for  the  involved  dbo_sh_asmt 
and  delete  it  •/ 

call  find_first_intersection_(sh_asmtref , 
"process->dbo_sh_asmt",  procrer. 
"dbo->dbo  sh_asmt",  dboref,  eos); 
call  delete_entity_Tsh_asmtref , "dbo_sh_asmt"); 
end; 

end; 

else  dc; 

/•  Release  the  database  object  from  access  by  the  process, 
but  retain  other  local  information  about  the  remote 
database  object  •/ 
if  inserted„( dboref , "process->dbo" ) 

then  call  remove_T dboref , "process->dbo"); 
else  do; 

call  find_first_intersection_(sh_asmtref , 
"process->dbo_sh asmt",  procref 
"dbo->dbo_sh_.asmt",  dboref, 
call  delete_entity_(sh_asmtref { "dbo 
end: 


eosj ; 
sh_asmt" 


): 


end:. 

/•  Create  an  entity  for  a remote  resource  release  and  the  declare  it 
as  a control  message  */ 
call  ereate_entity_(res_rel_ref , "res_rel"): 
call  create  attribute_(res_rel_ref,  "res_rei .rel_pnode_nameK , 

"field.  12,  p_proc_node  name); 

call  create  attrlbute_J>es_rel_ref , "res_rel.reI_proc_name'f, 

"field",  12,  p_process_narae) ; 

call  create  attribute,^ res  rel_ref,  "res_rel.dest_node_name" , 
"field",  12,  p_d¥o_node  name); 

call  create  attribute_(res  rel„rer , "res_rel.dest  dbo_name", 

"Yield",  12,  p d¥o_name); 

call  dcl_control_messageTres_rel_ref,  "res_rel",  cont  jase  numb) ; 
call  insert  (res  rel_ref.  "sys->control_message" , "last"7  SYS_REF) : 
call  write_Tist_T"Control  message  number",  cont_msg__numb, 

"sent  from",  p_proc„node_name , "to",  p_dDo_noce._name) ; 
call  write_list_("  representing  a remote  resource  release"); 

return: 
end: 


The  next  section  will  be  executed  if  the  process  and  database  object  are 
located  in  the  same  node  •/ 


Check  if  the  process  had  exclusive  control  of  the  database  object  •/ 
inserted_(dboref , "process->dbo") 
then  do: 

/*  Release  the  database  object  and  then  grant  at  least  one  other 
process  access  to  the  database  object' if  any  processes  are 
queued  for  it.  * / 

call  reraove._(oboref "process->dbo" ) : 
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call  write_list_( "Process",  p_proeess_jiaine,  "at  node", 
p_proc _node__name , "nas  released  database"); 
call  write_Iist_T"  object",  p_dbo_parae,  "at  node", 

d dbo_node_name); 

if  empty_j  dboref , "no<5e/dbo/mg->process") 

then  call  rem_proc_froni_queue(dboref , dbo  tableref); 
return; 
end; 
else  do; 

/•  Release  the  database  object  from  t.iis  shared  assignment,  and  if 
there  are  no  other  processes  currently  having  shared  access  to 
the  database  object  we  can  grant  another  process  access  to  the 
database  object  if  any  are  queued  for  it  */ 
call  find_firstjLnterseetion_(ahjasmtref,  "process->dbo_sh_asmt", 
procref,  "dbo->dbo_shw.asmt",  dboref,  eos); 
call  delete  entity  (sh_asmtref,  "dbo  .sh^asmt") ; 
call  write_list_("Proceas",  pmroeearjname-,  "at  node", 
p t>roo  nod^jnaae , "has  released  database"); 
call  write_Tlst_T"  object",  p._dbo_pame,  "at  node", 

p_dbo_node_nane ) ; 

if  member_coupt_(  dboref,  "dbo->dbo  sl\_asmt")  = 0 

then  if  emptv  (dboref , "node7dbo/mg->proeess") 

then  call  renuproc_fronL.queue(aboref , dbo_tableref); 

return; 

end; 


/•  REMOVE  PROCESS  FROM  QUEUE  6/V76  •/ 

remDroc_from  queue:  entry(p_dboref . p„dbo_tableref ) ; 

/•  This  procedure  will  grant  at  least  one  process  access  to  the  database 
object  that  is  referenced  by  "p_dboref"  (and  is  located  in  the  node  that 
has  its  own  node_table  referenced  by  "p_abo_tableref" ) . If  the  first 
process  on  the  queue  wants  exclusive  use  of  the  database  object,  then 
only  this  prooess  will  be  granted  access  to  the  dbo,  otherwise  all 
processes  that  requested  snared  access  and  that  are  in  front  (in  the 
queue)  of  all  processes  that  requested  exclusive  use  will  be  given 
shared  access  to  the  database  object  */ 

/*  Find  the  first  process  queued  for  the  database  object  e/ 
call  find  firs t_( procref,  "node/dbo/mg->process",  p dboref,  eos); 

/*  Check  Tf  the  process  wants  exclusive  use  of  the  database  object  */ 
if  extract  (procref,  "process. access__type" 5 = "exclusive" 
then  do; 

/•  Unblock  the  process  */ 

call  find_owner_( owner ref,  "node->prooess",  procref); 

call  remove_( procref , "node/dbo/mg->process") ; 

call  insert_( procref , "node/dbo/mg->process",  "first",  ownerref): 

/*  Give  the  process  exclusive  control  of  the  resource  */ 
call  insert_’p_dboref,  "procejs->dbo",  "first",  procref): 

/•  Get  the  names  of  tne  process,  dbo  and  nodes  involved  •/ 
dbo_name  = extract_(p_dboref , "dbo. name"); 
dbo_noae_name  s extract  (p.  dbo  tableref,  "node  table. name"); 
process_name  = extract_Tprocre7,  "process. name1* ) ; 
proc_node_name  = extract_( ownerref , "node_table.name") ; 

/•  Check  if  the  process  gaming  access  to  the  database  object  is  in 
the  same  node  as  the  abo  */ 
if  proc_node_name  = dbo„node_name 
then  do; 

call  write_list_( "Process" , process_name,  "at  node", 

proc  node_name,  "is  given  exclusive  use  of"): 
call  write  list_("  ",  dbo_naT2,  "at  node", 

abo_node_name) : 

return; 
end; 
else  do; 

/*  Create  a control  message  for  a remote  resourc 
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Procedure  REL 


return: 
end  REL: 


allocation  and  send  it  across  nodes.  */ 
call  dcl_rem_res__grant( dbo_node_name , dbo^naae, 

proc_node_name.  procesa_naae,  cont_jwg_nurab) ; 
call  write  list_(  "Control  message  number",  cont_msfL_numb, 
"sent  from",  dbo_node_name,  "to", 
proc  node_name) ; 

call  write  list_("  granting",  proeess_name, 

"exclusive  use  of",  dbo_name); 

return; 

end; 

end; 

else  do  while  ( eos); 

/•  The  first  process  on  the  queue  requested  shared  access  •/ 

/•  Unblock  the  process  */ 

call  find_owner_(ownerref , "node->process",  procref); 

call  remove_( procref , "noda/dbo/mg->proeess" ; ; 

call  insert_(procref , "node/dbo/ag->process",  "first",  ownerref); 

/•  Give  the  process  shared  access  to  the  database  object  */ 
call  dcl_dbo  sh_asmt(sh_asmtref): 

call  insert  Tsh_asmtref,  "dbo->dbo  sh_asmt",  "first",  p dboref); 

call  insert__(sh_asmtref , "prooess->dbo_sh_asmt"J  "firsts,  procref); 

/*  Get  the  names  of  the  process,  dbo  and  nodes  involved  V 

dbo_name  * extract  (p_dboref,  "dbo. name"); 

dbo_node_name  * extract {p_doo  tablersf,  "node  table. name"); 

process  name  * extraet_Tprocref , "process. name"); 

proc  node  name  a «xtraot_(ownerref , "node_table.name") ; 

/*  Check  if  the  process  gaining  access  to  the  database  object  is  in 
the  same  node  as  the  abo  •/ 
if  proc__node_name  = dbo_node_name 
then  do: 

call  write_list_( "Process",  process_name,  "at  node", 

proc  node_name,  "is  granted  shared  access  to"); 
call  write  lisT_("  ",  dbo_name,  "at  node", 

dbo_node_name) ; 

end; 

else  do; 

/*  Create  a control  message  for  a remote  resource 
allocation  and  send  it  across  nodes.  •/ 
call  dol_renLJ’es_grant(dbo_pode_name,  dbo_name, 

proc  n9de_name.  process_name,  cont_msg_numb) ; 
call  write  list_( "Control  message  number",  cont_jnsg_numb, 
"sent  from",  dbo_node_name,  "to", 
proc_node_name) ; 

call  write  llst_("  granting",  process_name, 

"shared  aocess  to",  dbo_name); 

end: 

/*  Find  what  it  now  the  first  process  queued  fcr  the  database 
object  •/ 

call  find_first_( procref , "node/Jbo/mg->process" , p_dboref,  eos): 

/*  If  this  process  wants  exclusive  control  of  the  database  object  it 
must  remain  blocked  and  we  will  not  remove  any  more  processes 
from  the  queue  '/ 

if  extract_( procref,  "process. access_type")  = "exclusive" 

V V% on  ana  — H 1 Wk» 

viivu  wWk''  =*  I 

end; 
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DDM_serv_routines 


/*  DDH_serv_routines.inei.pl1 

The  following  declarations  are  of  the  DDM  service  routines 


del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 

del 


check_for_deadlock  entrytfixed  bin(17),  chart  12), 

chart  12) , bit(l)); 

/*  Located  within  Procedure  OBPL  */ 
dol_dbo  entrytfixed  bir.(17),  char(12)); 

/•  Located  within  Procedure  DDM  */ 
ddjdbOLjshjasat  entrytfixed  bind?)); 

/•  Located  within  Procedure  DDM  */ 
dol_oontrol_jneasage  entrytfixed  bint  17),  char(20)t 

fixed  bin); 

/*  Located  within  Procedure  DDM  */ 
dcX_node_table  entry (fixed  bint  17),  chart  12)); 

/*  Located  within  Procedure  DDM  */ 
dcl_obpl  entrytfixed  bint  17),  chart  12), 

chart  12),  char(7)); 

/•  Located  within  Procedure  DDM  */ 
dcl_obpl_.cont.jBSg  entrytfixed  bint  17),  chart  12), 

chart  12)); 

/•  Located  within  Procedure  DDM  •/ 
dcl_proc_entry  entrytfixed  bint  17),  chart  12), 

chart*)); 

/•  Located  within  Procedure  DDM  •/ 
dcl_process  entrytfixed  bint  17),  chart  12)); 

/•  Located  within  Procedure  DDM  •/ 
delj>roc_term  entry (chart  12) , chart*),  chart  12)); 

/•  Located  within  Procedure  RCV  CM  •/ 
dcl_rem_rea_grant  entry(char(12),  chart*),  chart  12), 

chart*),  fixed  bin): 

/*  Located  within  Procedure  DDM  */ 
find_entity__loc  entrytfixed  bin(17),  char(20) 


fixed  bj.n(  17) , chart  12). 
‘ " ( 1 ) ) ; 


char(44))  returns  (bit 
/•  Located  within  Procedure  DDM  •/ 

entrytfixed  bint  17),  chart  12)); 
/*  Located  within  Procedure  OBPL  */ 
initiate_obpl 


exp_obpl 


Procedure  OBPL  ■/ 

entry?  chart  12)  | )OhaH*^(eh^r(  12 ) , 


/•  Located  within  Procedure  DDM  •/ 
obpl_add_resource  entrytfixed  bint  17),  fixed  bin(17), 

chart  12),  bit(D); 

/*  Located  within  Procedure  OBPL  */  . 

ueue  entrytfixed  bint  17),  fixed  bint  17)); 


re*_proc_froBL_ci 
rldbo 


oeated  within  Procedure  REL  */ 


/•  Located  within  Procedure  REL  */ 


rocedure  REL  V 

entrytehart*) , chart*),  chart*), 
chart*)); 
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ADT_prioitives 


/•75- 12-29 
These  are 
del 


ADT  primitives  designed 
add_ 

alter_ 

append_ 

break_ 

create_attri bute_ 

create„catalog_obJeet._ 

create.entity. 

create_group_ 

create.order. 

ereate_relationahip_ 

deleted. 

delete.entity. 

divide. 

empty. 

empty.interseotion. 

ent ity.c  la  ss_name_ 

enti ty.order.naae. 

exception^ 

extract. 

find.associatively. 


find_eatalog_obJect_ 

find.direct. 

find.eaeh. 

find.first. 

fi nd.fi rs  t.i n t e rs ec t i on. 


ADT_primi tives . incl . pi  1 
;ned  to  assist  the  funct 


o assist  the  function  definition  writer  •/ 
entry (char (128),  ohar(12B)) 

returns (chart  128)  varying); 
entry( fixed  bln(lt),  char(44), 
chart*) );  , „ , , 

entrytfixed  M.n(17),  char(20), 
char (6),  fixed  bint  17)); 
entry  (fixed  bint  17));  v 

entry  (fixed  bind  7),  chart 44), 
char|10j,  fixed  bin(17), 


f ind.first.uni  on. 


find.last. 

find.next. 


— j *. 

l Aim  ..  l.CA  U^AUWCI  ocv;wauu_ 


find.next.union. 


find.owner. 

find.nrior. 

insert. 

inserted 


chart  10),  fixed 
chart*))]  , 
entry (fixed  bint  17/, 
entrytfixed  bintIT;, 
entry (fixed  bint  1 7), 
entry (fixed  bin(l7), 
ehar(20));  „ 


char(*)): 
chari,20M; 
ohar(44)); 
ohar(20) , 


ehartzo)):  . , % 

entrytfixed  bin(17),  char(20), 

«?har(9).);  


returns (chart  128)  varying) 
entrytfixed  bin(17),  char(20); 

returns(bit(1)); 
entry(fixed  bin(17),  char(20), 
fixed  bint  17).  chart 20)) 


returns ( bit ( 
entry  (fixed  bind 
returns (char 
entrytfixed  bind 
returns(bit( 
entry; 


!}l£‘ 


char (20)) 


entrytfixed  bin(17) , ehar(44)) 
returns(char( 128)  varying); 
entrytfixed  bint  17),  ehar(20), 

fixed  bin(17),  chart  128)  varying, 
chart 44 ),  bit  D); 
entrytfixed  bint  17),  chart*)); 
entrytfixed  bin(17),  chert*)); 
entrytfixed  bin(17),  bit(l)): 


\ -V-T  / • W*  V V I / / ) 

fixed  bint  17),  chart*)); 
fixed  bin(l7),  chert*)); 
fixed  bln(17),  bit(1)): 
fixed  bin(17),  char(20), 
fixed  bint  17) , bitd)): 
entrytfixed  bin(17),  char(2c), 
fixed  bind?;,  char(2Q), 
fixed  bint  17),  bitd)): 
entrytfixed  bin(17J»  ehar(2o), 
fixed  bint  17),  char(20), 
fixed  bint  17),  bitd)); 
entrytfixed  bimlt),  char(20), 
fixed  bint  17),  bitd)); 
entrytfixed  bint  17;,  chart20), 
bit(l)); 

• / ...  J uj  - / \ -i /*>rsN 

cuti  y uaacu  uau\  i | j , uuai'uu;  y 

char (20),  bit(l)); 
entrytfixed  bin(17),  char(20), 
‘fixed  bint  17),  char(20), 
fixed  bint  17) , bit(1)>: 
entrytfixed  bind?),  char(20), 
fixed  bint  17) ) ; 

entrytfixed  bind?),  char(20), 
bit ( 1 ) ) ; 

entrytfixed  bind?),  char(20), 
char(6),  fixed  bind?)): 
entrytfixed  bind?),  char(20)) 
returns ( bi t ( 1 ) ; ; 


Appendix  II 


ADT_primitivea 


del  last_of_set_ 

del  member. 

del  member.oount. 

del  name_catalog.object_ 

del  aultiply_ 

del  owner. 

del  remove. 

del  3ort_j*elationahip_ 

del  subtract. 

/*  The  following  are  global  referenoe 

del  chcngesode 

del  SFJilF 

del  CN  HEF 

del  PRffC.REF 

del  PSPOEF 

del  PSSG.REF 

del  return  code 

del  SYS.REF 

del  tracemode 


entry( fixed  bin(17 
returns{blt( 1 
entry (fixed  bin(17 
returns (bit{1 
entry (fixed  bin(17 
returns (fixed 
entry (fixed 


j char(20)) 
j'ohar(20)) 


returna(ehar(44)  varying); 
sntry( char (128),  ehar(128)) 

returns (ehar( 128)  varying); 
entry  (fixed  bin07).  char(20)} 
returns(bit(1) J; 
entry( fixed  bin(17),  ehar(20 “ 
entry(fixed  bin(17) , char( 


[fixed  , 

, [fixed  bin( 
ehar(20)): 

entry(ohar(128),  char 
returns(char(128 


char(2oD’ 

variables  used  by  modellers**^/11^  ’ 
fixed  bin( 
fixed  bin 
fixed  bin 
fixed  bin 
fixed  bini 
fixed  bin( 

fixed  binary  external  static  init(6j;’ 
fixed  bin(l7)  external  static  init(o): 
bit('.)  external  static  init("0"b); 


(17 

external  statio; 

.17 

external  static  init 

;o) 

17 

external  static  init 

0 

17 

external  static  Init 

0) 

17 

external  static  init! 

0) 

(17) 

external  static  initl 

\o) 

Appendix  III 

This  appendix  contains  examples  of  several  deadlock  and  "near  deadlock" 
situations,  thus  demonstrating  various  features  of  the  deadlock  detection  al- 
gorithm presented  in  Chapter  VX.  In  the  case  where  a deadlcck  is  detected,  a 
final  state  diagram  is  given,  whereas  in  the  examples  where  no  deadlock  is 
detected,  an  important  intermediate  state  is  also  shown.  A key  to  the 
diagrams  appears  on  the  next  page.  Diagrams  appear  on  a page  with  a header 
containing  the  name(s)  of  the  associated  scenario(s).  Each  diagram  immedi- 
ately follows  the  first  scenario  with  which  it  is  associated. 

It  should  be  noted  that  before  the  commands  specific  to  each  example  were 
executed,  after  the  system  state  was  reinitialized,  the  commands  in  file 
"demoO"  were  executed. 
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Key  for  State  Diagrams  of  Demonstration  Scenarios 


Represents  process  "pi**  as  the  initiator  of  message 
group  "mgj".  (pi)  and  /ag}\  are  always  in  the  same 
node  to7'  this  representation. 

Represents  process  "pi"  as  the  acceptor  of  message 
group  "mgj"  and  "pi"  is  currently  waiting  for  a mes- 
sage in  "mgj".  (£3)  and  /tag)\ need  not  be  in  the 
same  node  for  this  representation. 

Represents  process  "pk"  waiting  for  a message  from 
operator  "opi*  over  operator  connection  "conj". 

Represents  operator  "opi"  waiting  for  a message  from 
process  "pk"  over  operator  connection  "conj". 


acees3_type 


Represents  process  "pi"  as  having  access  to  database 
object  "dbok".  The  type  of  access  is  specified  by 
"access_type" . (£1)  and  [dbok]  n^ed  not  be  in  the 

same  node. 


acceas_type 


Hdbok] 


Represents  process  "pi"  as  waiting  for  access  to 
database  object  "dbok".  The  type  of  access  desired 
is  specified  by  "access_type".  and  [dbok]  need 

net  be  in  the  same  node. 


Represents  a node  with  the  node  name  specified  by 
"city".  (pi)  and  [dbok]  drawn  "within"  this  node 
represent  processes  and  database  objects^located 
within  the  node  specified  by  "city",  drawn 

"within"  the  node  represents  a message  group  that  was 
initiated  by  a process  located  i?i  the  node  specified 
by  "city". 
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Appendix  III  scenario  demoO 


scenario  demo3 
sysgen 

System  created 
cnode  Boston 
Node  created:  Boston 

cnode  Phoenix 
Node  created : Phoenix 

cproc  Boston  pi 

Process  pi  created  in  node  Boston 

cproc  Boston  p2 

Process  p2  created  in  node  Boston 

i j!  cproc  Boston  p3 

i S Process  p3  created  in  node  Boston 

j I cdbo  Boston  dbol 

< < Database  object  dbol  created  in  node  Boston 

. I cdbo  Boston  dbo2 

, Database  object  dbo2  created  in  node  Boston 

; cproc  Phoenix  pi 

j Process  pi  oreated  in  node  Phoenix 

! oproc  Phoenix  p2 

Process  p2  created  in  node  Phoenix 

cproc  Phoenix  p3 

Process  p§  created  in  node  Phoenix 

cdbo  Phoenix  dbol 

Database  object  dbc1  created  in  node  Phoenix 

cdbo  Phoenix  abo2 

Database  objeot  dbo2  created  in  node  Phoenix 

cnode  Cambridge 

Node  created:  Cambridge 

cproc  Cambridge  pi 

Process  pi  created  in  node  Cambridge 

cproc  Cambridge  p2 

Process  p2  created  in  node  Cambridge 

cproc  Cambridge  p3 

Process  p3  created  in  node  Cambridge 

cdbo  Cambridge  dbol 

Database  object  dbol  created  in  node  Cambridge 

cdbo  Cambridge  dbo2 

: Database  object  dbo2  oreated  ir  node  Cambridge 
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Appendix  III  scenario  demo_bug 


scenario  deno_bug 

note  This  is  an  example  of  a case  where  a deadlock  Involving  two 
note  processes  and  two  resources  located  in  two  nodes  is  detected, 
note  when  in  fact  no  deadlock  exists.  The  reason  a deadlock  is 

note  detected  is  that  an  OBPL  sent  from  Boston  to  Phoenix  had  its 

note  arrival  delayed  long  enough  so  that  pi  in  Phoenix  could  release 

note  dbol  in  Boston,  request  access  to  it  again,  gain  use  of  the 

note  database  object  end  then  request  access  to  and  get  queued  for 

note  dbol  in  Phoenix  before  Phoenix  examined  the  OBPL.  The  first 

note  seven  commands  set  up  the  state  where  pi  in  Phoenix  has  exclusive 

note  use  of  dbol  in  Boston,  pi  in  Boston  has  shared  use  cf  dbol  in 

note  Phoenix,  pi  in  Boston  in  blocked  waiting  for  shared  use  of  dbol 

note  in  Boston,  and  an  OBPL  has  been  sent  to  Phoenix  by  Boston, 

rqdbo  shared  Boston  pi  Phoenix  dbol 

Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 

Control  message  number  1 sent  from  Boston  to  Phoenix 

representing  a remote  resource  request 

revem  1 

Control  message  number  1 representing  a remote  resource  request 
has  been  reoeived 

pi  at  rode  Boston  is  granted  shared  access  to 

dbol  at  node  Phoenix 

Control  message  number  2 sent  from  Phoenix  to  Boston 

representing  this  allocation 

revem  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Boston  has  been  granted  shared  access  to 

dbol  at  node  Phoenix 

rqdbo  exclusive  Phoenix  pi  Boston  dbol 

Process  pi  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  lue  desired  resource 

Control  message  number  3 sent  from  Phoenix  to  Boston 
representing  a remote  resource  request 

revem  3 

Control  message  number  3 representing  a remote  resource  request 
has  been  received 

pi  at  node  Phoenix  is  granted  exclusive  use  of 

dbol  at  node  Boston 

Control  message  number  4 sent  from  Boston  to  Phoenix 

representing  this  allocation 

revem  4 

Control  message  number  4 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Phoenix  has  been  granted  exclusive  use  of 

dbol  at  node  Boston 

rqdbo  shared  Boston  pi  Boston  dbol 

Resource  not  available,  process  blocked. 

Control  message  number  t>  sent  from  Boston  to  Phoenix 

representing  an  OBPL 

note  Do  not  let  the  OBPL  be  received  at  this  time.  Let  pi  in  Phoenix 
note  release  dbol  in  Boston,  so  that  pi  in  Boston  will  be  awakened  and 

note  granted  shared  use  of  dbol  in  Boston, 

rldbo  Phoenix  pi  Boston  dbol 

Control  message  number  6 sent  from  Phoenix  to  Boston 
representing  a remote  resource  release 

revorn  6 

Control  message  number  6 representing  a remote  resource  release 
has  been  received 

dbc1  at  node  Boston  has  been  released  by- 

pi  at  node  Phoenix 

Process  pi  at  node  Boston  is  granted  shar* J access  to 

dbol  at  node  Boston 

note  Let  pi  in  Phoenix  request  access  to  dbol  in  Boston  f o:  ‘...e 
note  second  time,  and  let  it  be  grantea  shared  use  of  the  database 
note  object. 
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scenario  demo_bug 


Boston 


resource  request 


rqdbo  shared  Phoenix  pi  Boston  dbol 
Process  pi  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  7 sent  from  Phoenix  to 
representing  a remote  resource  request 

rcvcm  7 

Control  message  number  7 representing  a remote 
has  been  received 
pi  at  node  Phoenix  is  granted  shared  aoceas  to 

dbol  at  node  Boston 

Control  message  number  8 sent  from  Boston  to  Phoenix 

representing  this  allocation 

rcvcm  8 

Control  message  number  8 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Phoenix  has  been  granted  shared  access  to 

dbol  at  node  Boston 

note  Let  pi  in  Phoenix  request  exclusive  use  of  dbol  In  Phoenix, 
note  The  process  will  be  blocked  and  an  OBPL  will  be  sent  to  Boston 

note  where  it  will  be  discarded  because  pi  in  Boston  is  active, 

rqdbo  exclusive  Phoenix  pi  Phoenix  dbol 

Resouroe  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Phoenix  is  blocked. 

Control  message  number  9 sent  from  Phoenix  to  Boston 

representing  an  OBPL 

rcvcm  9 


Control  message  number  9 representing  an  OBPL  has  been  received. 

5te  Now  let  Phoenix  receive  the  OBPL  that  was  previously  sent  by 

ste  Boston.  A "false"  deadlock  will  be  detected  because  pi  in  Phoenix 


note 
note 

note  is  blocked  and  has  access  to  dbol  in  Boston,  even  though  this  is 
note  not  the  same  assignment  of  the  resource  that  was  used  when  the 
note  OBPL  was  created, 
rcvcm  5 

Control  message  number  5 representi..T  an  OBPL  has  been  received. 

A deadlock  has  been  detected.  The  fol  owing  processes  are  involved: 

pi  at  none  Boston 

pi  at  node  Phoenix 

End  of  deadlock  list 
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scenario  demo_bug 


i 

I 


State  where  control  message  5 representing  an  OBPL  has  j 
from  Boston  to  Phoenix.  Receipt  of  tne  OBPL  is  delayed  until 
drawn  below  has  drawn  been  reached. 


ust  been  sent 
after  the  state 


Boston  Phoenix 

Final  State  Diagram 


1M 


I note  This  is  an  example  of  a two  proeess  two  resource  deadlock  in  a 

note  single  rode.  No  control  messages  and  no  operators  are  involved 
note  in  the  detection  of  this  deadlock, 
initsg  mgl  Boston  p2  Boston 
Message  group  mgl  has  been  initiated 
acceptmg  mgl  Boston  pi 

m$i  has  been  accepted  by  pi  at  node  Boston 
rqdoo  shared  Boston  pi  Boston  dbol 

p‘l  at  node  Boston  granted  shared  access  to  dbol  at  node  Boston 
rqdbo  exclusive  Boston  p2  Boston  dbol 
Resource  is  not  currently  available  for  exclusive  use,  process  p2 
at  node  Boston  is  blocked. 

I rcvmsg  mgl 

: Process  pi  at  node  Boston  is  blocked  waiting  for  a 

f message  in  message  group  mgl 

A deadlock  has  been  detected.  Tne  following  processes  are  involved: 

pi  at  node  Boston 

p2  at  node  Boston 

End  of  deadlook  list 


Boston 

Final  State  Diagram 


] 

I 
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scenario  demo2 


scenario  demo2 

note  This  is  an  example  of  a two  crcosss  tno  resource  deadlock 

note  involving  two  nodes.  The  first  three  commands  create  the  state 

note  where  both  processes  are  active  and  both  involved  resources  have 

note  been  allocated  to  the  proper  processes, 
rqdbo  exclusive  Phoenix  pi  Phoenix  dbol 
pi  at  node  Phoenix  is  granted  exclusive  use  of  dbol  at  node  Phoenix 
ini tag  ag2  Cambridge  pi  Phoenix 
Message  group  age  hea  been  initiated 
accepiag  mg2  Pnoenix  pi 

a g2  has  been  accepted  by  pi  at  node  Phoenix 

rqdbo  shared  Cambridge  pi  Phoenix  dbol 

Process  pi  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Cambridge  to 
representing  a remote  resource  request 
note  We  will  delay  thi 
rcvmsg  mg2 


Phoenix 

3the  receipt  by  Phoenix  of  this  resource  request. 


Process 


is  blocked  waiting  for  a 


to  Cambridge 


pi  at  node  Phoenix 

message  in  message  group  mg2 
Control  message  number  2 sent  from  Phoenix 
representing  an  OBPL 

revem  2 

Control  message  number  2 representing  an  OBPL  has  been  reoeived. 
Control  message  number  3 sent  from  Cambridge  to  Phoenix 
representing  an  OBPL 

note  This  OBPL  contains  entries  for  pi  in  Phoenix  and  pi  in  Cambridge, 

note  It  will  be  discarded  by  Phoenix  because  Phoenix  has  no  record  that 

note  pi  in  Cambridge  is  waiting  for  dbol  in  Phoenix  since  control 
note  message  1 still  has  not  been  reoeived. 
revem  3 

Control  message  number  3 representing  an  OBPL 
revem  1 

Control  message  number  1 representing  a remote 
has  Been  received 

Resource  not  available,  process  remains  blocked. 

Control  message  number  4 sent  from  Phoenix 
representing  an  OBPL 

This  OBPL  contains  entries  for  pi  in  Cambridge  and  pi  in  Phoenix. 


has  been  received, 
resource  request 


to  Cambridge 


note 
note 
note 
note 
revem  4 


It  states  that  pi  in  Phoenix  is  waiting  for  a message  in  message 
group  mg2.  Cambridge  will  verify  that  the  desired  message  has 
not  been  sent,  and  a deadlock  will  be  detected. 


Control  message  number  4 representing  an  OBPL  has  been  received. 

A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Cambridge 

pi  at  node  Phoenix 

End  of  deadlock  list 
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scenario  demo  3 


scenario  demo  3 

note  This  is  an  example  of  a two  process  two  resource  deadlock 
note  involving  two  nodes.  The  first  three  commands  create  the  state 

note  where  both  processes  are  active  and  both  involved  resources  have 

note  been  allocated  to  the  proper  processes, 
rqdbo  exclusive  Phoenix  pi  Phoenix  dbol 

fi  at  node  Phoenix  Is  granted  exclusive  use  of  dbol  at  node  Phoenix 
tmg  mg2  Cambridge  pi  Phoenix 
Message  group  mg2  has  been  initiated 
accepting  mg2  Phoenix  pi 

mg2  has  been  accepted  by  pi  at  node  Phoenix 
rqdbo  shared  Cambridge  pi  Phoenix  dbol 
Process  pi  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Cambridge  to  Phoenix 
representing  a remote  resource  request 
note  He  will  delay  receipt  by  Phoenix  of  this  resource  request  just 
note  long  enough  to  block  pi  in  Phoenix  (which  controls  dbol  in  Phoenix) 

note  and  send  an  OBPL  to  Cambridge.  In  this  way,  after  receipt  of  the 

note  resource  request,  we  will  have  two  OBPL's  outstanding,  and  the  same 

note  deadlock  will  be  detected  twice, 
rcvmsg  mg2 

Process  pi  at  node  Phoenix  is  blocked  waiting  for  a 

message  in  message  group  mg2 

Control  message  number  2 sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

revcm  1 

Control  message  number  1 representing  a remote  resource  request 
has  been  received 

Resource  not  available,  prooess  remains  blocked. 

Control  message  number  3 sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

revcm  2 

Control  message  number  2 representing  an  OBPL  has  been  received. 

Control  message  number  4 sent  from  Cambridge  to  Phoenix 

representing  an  OBPL 

revcm  3 

Control  message  number  3 representing  an  OBPL  has  been  received. 

A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Cambridge 

pi  at  node  Phoenix 

End  of  deadlock  list 

reven  4 

Control  message  number  4 representing  an  OBPL  has  been  received. 

A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Phoenix 

pi  at  node  Cambridge 

End  of  deadlock  list 


1R- 


Appendix  III 
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dbol  at  node  Phoenix 


scenario  demo4 

note  This  is  an  example  of  a two  process  two  resource  deadlock 
note  involving  two  nodes.  The  first  three  commands  create  the  state 

note  where  both  processes  are  active  and  both  involved  resources  have 

note  been  allocated  to  the  proper  processes, 
rqdbo  exclusive  Phoenix  pi  Phoenix  dbol 
pi  at  node  Phoenix  is  granted  exclusive  use  of 
ini tog  mg2  Cambridge  pi  Phoenix 
Message  group  mg2  has  been  Initiated 
accepting  mg 2 Phoenix  pi 

mg2  has  been  accepted  by  pi  at  node  Phoenix 
rqdbo  shared  Cambridge  pi  Phoenix  dbol 
Process  pi  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Cambridge  to  Phoenix 
representing  a remote  resource  request 
note  We  will  allow  this  resource  request  to  be  immediately  received 

note  by  Phoenix.  No  OBPL  will  be  generated  because  pi  in  Phoenix  is 

note  active,  and  it  controls  dbol  in  Phoenix.  By  default,  control 
note  messages  generated  in  the  future  will  be  received  immediately 
note  after  they  are  sent,  and  the  deadlock  will  be  detected  once, 
rcvem  1 

Control  message  number  1 representing  a remote 
has  been  received 
Resource  not  available,  process  remains  blocked, 
rcvmsg  mg2 

Process  pi  at  node  Phoenix  is  blooked  waiting  for  a 

message  in  message  group  mg2 
Control  message  number  2 sent  from  Phoenix 
representing  an  OBPL 

rcvcm  2 


resource  request 


to  Cambridge 


Control  message  number  2 representing  an  OBPL  has  been  received. 
Control  message  number  3 sent  from  Cambridge  to  Phoenix 
representing  an  OBPL 

rcvcm  3 

Control  message  number  3 representing  an  OBPL  has  been  received. 

A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Phoenix 

pi  at  node  Cambridge 

End  of  deadlock  list 
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scenario  demo5 

note  This  is  an  example  of  a state  where  two  deadlocks  exist 
note  involving  four  processes  and  four  resources  located  in  three 
note  nodes.  Two  deadlocks  are  involved  because  dbol  in  Cambridge 
note  has  two  shared  users.  The  first  10  commands  create  the  state 

note  where  all  the  involved  processes  are  active  and  all  the  involved 

note  resources  have  been  allocated  to  the  proper  processes, 
initmg  mgl  Boston  pi  Cambridge 
Message  group  mgl  has  been  initiated 
accepting  mgl  Cambridge  pi 

mgl  has  been  accepted  by  pi  at  node  Cambridge 
rqdbo  shared  Cambridge  pi  Cambridge  dbol 
pi  at  node  Cambridge  granted  shared  access  to  dbol  at  node  Cambridge 
rqdbo  shared  Boston  pi  Cambridge  dbol 
Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Boston  to  Cambridge 
representing  a remote  resource  request 

rcvom  1 

Control  message  number  1 representing  a remote  resource  request 
has  been  received 

pi  at  node  Boston  is  granted  shared  access  to 

dbol  at  node  Cambridge 

Control  message  number  2 sent  from  Cambridge  to  Boston 
representing  this  allocation 

rcvcm  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Boston  has  been  granted  shared  access  to 

dbol  at  node  Cambridge 

rqdbo  exclusive  Cambridge  p2  Phoenix  dbol 
Process  p2  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  3 sent  from  Cambridge  fcc  Phoenix 
representing  a remote  resource  request 

rcvcm  3 

Control  message  number  3 representing  a remote  resource  request 
has  been  received 

p2  at  node  Cambridge  is  granted  exclusive  use  of 

dbol  at  node  Phoenix 

Control  message  number  4 sent  from  Phoenix  to  Cambridge 

representing  this  allocation 

rcvcm  4 

Control  message  number  4 representing  a remote  resource  allocation 
has  been  received 

p2  at  node  Cambridge  has  been  granted  exclusive  use  of 

dbol  at  node  Phoenix 

rqdbo  shared  Phoenix  pi  Phoenix  dbo2 

pi  at  node  Phoenix  granted  shared  access  to  dbo2  at  node  Phoenix 
rqdbo  exclusive  Boston  p i Phoenix  dbo2 

Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  b sent  from  Boston  to  Phoenix 
representing  a remote  resource  request 
note  No  OBPL  will  be  sent  to  another  node,  anckno  deadlock  will 
note  be  detected  because  pi  at  node  Phoenix  is  active  and  is  the  only 
note  process  that  has  access  to  dbo2  in  Phoenix, 
rcvcm  5 

Control  message  number  5 representing  a remote  resource  request 
has  been  received 

Resource  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Boston  remains  blocked 

rqdoo  shared  Phoenix  pi  Phoenix  dbol 
Resource  not  available,  process  blocked. 

Control  message  number  6 sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 
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scenario  demo5 


note  No  deadlock  will  be  detected  because  p2  in  Cambridge  is  active, 
rcvom  6 

Control  message  number  6 representing  an  OBPL  has  been  received, 
note  This  next  request  will  create  a three  process  three  resource 
note  deadlock.  An  OBPL  will  be  created,  and  we  will  immediately  pass 

note  it  from  node  to  node  in  order  to  detect  the  deadlock, 

rqdbo  exclusive  Cambridge  p2  Cambridge  dbol 

Resource  is  not  currently  available  for  exclusive  use,  process  p2 
at  node  Cambridge  is  blocked. 

Control  message  number  7 sent  from  Cambridge 
representing  an  OBPL 

rcvcm  7 

Control  message  number  7 representing  a 
Control  message  number  8 sent  from  Boa 
representing  an  OBPL 

rcvcm  8 

Control  message  number  8 representing  an  OBPL 
A deadlock  h*a  been  detected.  The  following  processes  are  involved: 

p2  at  node  Cambridge 

pi  at  node  Boston 

pi  at  node  Phoenix 

End  of  deadlock  list 

note  The  next  command  will  create  a four  oroeess  four  resource  deadlock, 
note  Due  to  the  fact  that  two  processes  have  shared  access  to  dbol  in 

note  Cambridge,  both  this  newly  created  deadlock,  and  the  previously 

note  detected  deadlock  will  be  detected  when  the  OBPL  is  created  and 
note  passed  among  the  nodes. 


an  OBPL 
>ston 


to  Boston 


has  been  received, 
to  Phoenix 


has  been  received. 


rcvmsg  mgl 

Process  pi  at  node  Cambridge 

message  in  message  group  mgl 

Control  message  number  9 sent  from  Cambridge 
representing  an  OBPL 

rcvcm  9 

Control  message  number  9 representing  an  OBPL 

Control  message  number  10  sent  from  Boston 
representing  an  OBPL 

rcvcm  10 

Control  message  number  10  representing  an  OBPL 

Control  message  number  11  sent  from  Phoenix 
representing  an  OBPL 

rcvcm  11 

Control  message  number 


is  blocked  waiting  for  a 
to  Boston 


has  been  received, 
to  Phoenix 


has  been  received, 
to  Cambridge 


A deadlock  has  been  detected. 

P] 

P 

Pi 

p2 

End  of  deadlock  list 
A deadlock  has  been  detected. 

P] 

Pi 

P? 

End  of  deadlock  list 


11  representing  an  OBPL  has  been  received. 


The  following  processes  are  involved: 


at  node 
at  node 
at  node 
at  node 


Cambridge 

Boston 

Phoenix 

Cambridge 


The  following  processes  are  involved: 
e t node  Boston 

at  node  Phoenix 

at  node  Cambridge 
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scenario  demo6 


Cambridge 


resource  request 


pi 


scenario  demofc 

note  This  is  an  example  of  a state  where  two  deadlocks  exist 
note  involving  four  processes  and  four  resources  located  in  three 
note  nodes,  two  deadlocks  are  involved  because  dbol  in  Cambridge 
note  has  two  shared  users.  The  first  10  commands  create  the  state 

note  where  all  the  involved  processes  are  active  and  all  the  involved 

note  resources  have  been  allocated  to  the  proper  processes, 
initmg  mgl  Boston  pi  Cambridge 
Message  group  mgl  has  been  initiated 
accepting  mgl  Cambridge  pi 

mgl  has  been  accepted  by  pi  at  node  Cambridge 
rqdbo  shared  Cambridge  pi  Cambridge  dbol 
pi  at  node  Cambridge  granted  shared  access  to  dbol  at  node  Cambridge 
rqdbo  shared  Boston  pi  Cambridge  dbol 
Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Boston  to 
representing  a remote  resource  request 

rcvcm  1 

Control  message  number  1 representing  a remote 
has  been  received 

at  rode  Boston  is  granted  shared  access  to 

dbol  at  node  Cambridge 

Control  message  number  2 sent  from  Cambridge  to  Boston 
representing  this  allocation 

rcvcm  2 

Control  message  number  2 representing  a remote 
has  been  received 

at  node  Boston  has  been  granted  shared  access  to 

dbol  at  node  Cambridge 

rqdbo  exclusive  Cambridge  p2  Phoenix  dbol 

Process  p2  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  3 sent  from  Cambridge  to  Phoenix 
representing  a remote  resourcs  request 

rcvcm  3 

Control  message  number  3 representing  a remote  resource  request 
has  Been  received 

at  node  Cambridge  is  granted  exclusive  use  of 
dbol  at  node  Phoenix 

Control  message  number  4 sent  from  Phoenix  to  Cambridge 

representing  this  allocation 

rcvcm  4 

Control  message  number  4 representing  a remote  resource  allocation 
has  been  received 

at  node  Cambridge  has  been  granted  exclusive  use  of 
dbol  at  node  Phoenix 

rqdbo  shared  Phoenix  pi  Phoenix  dbo2 


resource  allocation 


pi 


p2 


P2 


dbo2  at  node  Phoenix 


pi  at  node  Phoenix  granted  shared  access  to 
rqdbo  exclusive  Boston  pi  Phoenix  dbo2 

Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  5 sent  from  Boston  to  Phoenix 
representing  a remote  resource  request 
note  pi  in  Phoenix  is  active,  so  there  will  be  no  deadlock  when  the 
note  remote  resource  request  is  received  from  Boston, 
rcvcm  *5 

Control  message  number  5 representing  a remote  resource  request 
has  been  received 

Resource  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Boston  remains  clocked 

rqdbo  snared  Phoenix  pi  Phoenix  dbol 

Resource  not  available,  process  blocked. 

Control  message  number  6 sent  from  Phoenix 
representing  an  OBPL 


to  Cambridge 
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p2  in  Cambridge  is  active,  so  the  CBPL  will  be  discarded  after 
it  is  received  by  Cambridge. 

6 representing  an  08PL  has  been  received. 

is  blocked  waiting  for  a 

to  Boston 


note 
note 
rcvem  6 
Control  message  number 
rcvmsg  mgl 
Process  pi 


at  node  Cambridge 


message  in  message  group  mgl 

ent  from  Cambridge 


Control  message  number  7~  sent 
representing  an  OBPL 

note  p2  in  Cambridge  is  active,  so  the  OBPL  will  be  discarded  when 
note  it  reaches  Cambridge, 
rcvcm  7 

Control  message  number  7 representing  an  OBPL 
Control  message  number  8 sent  from  Boston 
representing  an  OBPL 

rcvcm  8 

Control  message  number  8 representing  an  OBPL 
Control  message  number  9 sent  from  Phoenix 
representing  an  OBPL 

rcvcm  9 

Control  message  number  9 representing  an  OBPL  has  been  received. 

This  next  request  will  create  two  deadlocks,  due  to  the  fact  that 
dbol  in  Cambridge  has  two  readers.  Two  OBPL’s  will  be  generated, 
and  both  deadlocks  will  be  detected  when  their  respective  OBPL's 


has  been  reoeived. 
to  Phoenix 


has  been  received, 
to  Cambridge 


note 
note 
note 
note 
note 
note 

note  in  Phoenix . 
rqdbo  exclusive  Cambridge  p2  Cambridge  dbol 
Resource  is  not  currently  available  for  exclusive  use,  process  p2 
at  node  Cambridge  is  blocked. 

Control  message  number  10  sent  from  Cambridge 
representing  an  OBPL 

Control  message  number  11  sent  from  Cambridge 
representing  an  OBPL 

rcvcm  10 

Control  message  number  10  representing  an  OBPL 
Control  message  number  12  sent  from  Boston 
representing  an  OBPL 

rcvem  12 

Control  message  number  12  representing  an  OBPL 
A deadlock  has  been  detected. 

P? 

Pi 

End  of  deadlock  list 

rcvcm  11 

Control  message  number  1 1 representing 

Control  message  number  13  sent  from 
representing  an  OBPL 

rcvcm  13 

Control  message  number  13  representing  en  OBPL  has  been  received. 
A deadlock  has  been  detected.  The  following  processes  are  involved: 

p2  at  node  Cambridge 

pi  at  node  Boston 

pi  at  node  Phoenix 

End  of  deadlock  list 


arrive  in  Phoenix.  The  0BPLfs  need  not  return  to  Cambridge 
because  p2  in  Cambridge  was  the  first  process  to  be  placed  in  the 
OBPL's,  and  Phoenix  knows  that  p2  in  Cambridge  oontrols  dbol 


to  Boston 
to  Boston 


has  been  received, 
to  Phoenix 


has  been  received. 
The  following  processes  are  involved: 
at  node  Cambridge 
Cambridge 
Boston 
Phoenix 


at  nod  ft 
at  node 
at  node 


an  OBPL 
Boston 


has  been  received, 
to  Phoenix 
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Boston 


resource  request 


scenario  demo7 

note  This  is  an  example  of  a state  where  three  deadlocks  exist 
note  involving  six  processes  and  five  resources  located  in  three 

note  nodes.  Three  deadlocks  are  involved  because  dbo2  in  Boston 

note  has  three  shared  users.  Five,  rather  than  six,  resources  are 

note  involved  because  two  processes  are  waiting  for  the  same  database 

note  object.  The  first  18  commands  create  the  state  where  all  the 

note  involved  processes  are  active  and  all  the  involved  resources 

note  have  been  allocated  to  the  proper  processes . 
rqdbo  shared  Boston  pi  Boston  dbo2 

pi  at  node  Boston  granted  shared  access  to  dbo2  at  node  Boston 
i nit mg  mgl  Phoenix  pi  Boston 
Message  group  mgl  has  been  initiated 
accepting  mgl  Boston  pi 

mgl  has  been  accepted  by  pi  at  node  Boston 
rqdbo  exclusive  Phoenix  p2  Boston  dbol 
Process  p2  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Phoenix  to 
representing  a remote  resource  request 

rcvcm  1 

Control  message  number  1 representing  a remote 
has  been  received 
p2  at  node  Phoenix  is  granted  exclusive  use  of 

dbol  at  node  Boston 

Control  message  number  2 sent  from  Boston  to  Phoenix 

representing  this  allocation 

rcvcm  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  received 

p2  at  node  Phoenix  nas  been  granted  exclusive  use  of 

dbol  at  node  Boston 

rqdbo  shared  Cambridge  pi  Boston  dbo2 

Process  pi  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  3 sent  from  Cambridge  to  Boston 
representing  a remote  resource  request 

rcvcm  3 

Control  message  number  3 representing  a remote  resource  request 
has  been  received 

pi  at  node  Cambridge  is  granted  shared  access  to 

dho2  at  node  Boston 

Control  message  number  4 sent  from  Boston  to  Cambridge 

representing  this  allocation 

rcvcm  4 

Control  message  number  4 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Cambridge  has  been  granted  shared  access  to 

dfco2  at  node  Boston 

rqdbo  shared  Cambridge  p2  Boston  dbo2 

Process  p2  at  node  Cambridge  is  blocked  whilt  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  b sent  from  Cambridge  to  Boston 
representing  a remote  resource  request 
rqdbo  shared  Phoenix  pi  Cambridge  dbol 

Process  pi  at  node  Phoenix  is  blocked  while  a reouest  is  sent  to 
tne  node  containing  the  desired  resource 
('ontrol  messatre  number  6 sent  from  Phoenix  to  Cambridge 
representing  a remote  resource  request 


r eve-"  j 
Control 


.To 


message  number  5 representing  a remote  resource  request 
has  been  received 

at  node  Cambridge  is  granted  ahared  access  to 
ibc?  at  node  Boston 

message  number  7 sent  from  host on  to  Cambridge 

rerretri" tine  this  allocation 


i , 
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rcvcm  6 

Control  message  number  6 representing  a remote  resource  request 
has  been  received 

pi  at  node  Phoenix  is  granted  shared  access  to 

dbol  at  node  Cambridge 

Control  message  number  8 sent  from  Cambridge  to  Phoenix 

representing  this  allocation 

rcvcm  7 

Control  message  number  7 representing  a remote  resource  allocation 
has  been  received 

p2  at  node  Cambridge  has  been  granted  shared  access  to 

dbo2  at  node  Boston 

rcvcm  8 

Control  message  number  8 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Phoenix  has  been  granted  shared  access  to 

dbol  at  node  Cambridge 

rqdbo  exclusive  Cambridge  p3  Phoenix  dbol 

Process  p3  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 

Control  message  number  9 sent  from  Cambridge  to  Phoenix 
representing  a remote  resource  request 

rcvcm  9 

Control  message  number  9 representing  a remote  resource  request 
has  been  received 

p3  at  node  Cambridge  is  granted  exclusive  use  of 

dbol  at  node  Phoenix 

Control  message  number  10  sent  from  Phoenix  to  Cambridge 

representing  this  allocation 

rcvcm  10 

Control  message  number  10  representing  a remote  resource  allocation 
has  been  received 

p3  at  node  Cambridge  has  been  granted  exclusive  use  of 

dbol  at  node  Phoenix 

rcvmsg  mgl 

Process  pi  at  node  Boston  is  blocked  waiting  for  a 

message  in  message  group  mgl 

Control  message  number  11  sent  from  Boston  to  Phoenix 

representing  an  OBPL 

note  The  OBPL  will  be  discarded  by  Phoenix  because  pi  is  active, 
rcvcm  1 1 

Control  message  number  11  representing  an  OBPL  has  been  received, 
rqdbo  shared  Cambridge  pi  Boston  dbol 

Process  pi  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 

Control  message  number  12  sent  from  Cambridge  to  Boston 
representing  a remote  resource  request 
note  The  process  that  controls  dbol  in  Boston  is  located  In  Phoenix, 
note  and  is  active..  Therefore,  when  Boston  receives  the  resource 

note  request,  it  v I create  an  OBPL  and  send  it  to  Phoenix,  which 

note  will  then  di.r  ird  it. 
rcvcm  12 

Control  message  number  12  representing  a remote  resource  request 
has  Been  received 

Resource  not  available,  process  remains  blocked. 

Contrcl  message  number  1?__?ent  from  Boston  to  Phoenix 

» cyi  an  'JDrb 

rcvcm  13 

Control  message  number  13  representing  an  OBPL  has  been  received, 
rqdbo  exclusive  Phoenix  p2  Phoenix  dbol 

Resource  not  available,  process  blocked. 

Control  message  number  *4  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

note  The  OBPL  will  be  discarded  by  Cambridge  because  p3,  which  controls 

note  dbol  in  Phoenix,  is  active. 

revert  1*‘ 

Coutr-T  message  nuib  or  14  represent  in?  an  OBPL  has  b*-*en  received 


Appendix  III 


scenario  demo? 


rqdbc  exclusive  Cambridge  p3  Cambridge  dbol 

Resource  is  not  currently  available  for  exclusive  use,  process  p3 
at  node  Cambridge  is  blocked. 

Control  message  number  15  sent  from  Cambridge  to  Phoenix 
representing  an  ObPL 

note  The  OBPL  will  be  disoarded  by  Phoenix  beoause  pi,  which  controls 
note  dbol  in  Cambridge,  is  active, 
rcvcm  15 

Control  message  number  15  representing  an  OBPL  has  been  received, 
rqdbo  shared  Cambridge  p2  Phoenix  dbol 

Process  p2  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 

Control  message  number  16  sent  from  Cambridge  to  Phoenix 
representing  a remote  resource  request 

rcvcm  16 

Control  message  number  16  representing  a remote  resource  request 
has  been  received 

Resource  not  available,  process  remains  blocked. 

Control  message  number  17  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

note  An  OBPL  is  sent  to  Cambridge  beoause  p3  in  Cambridge  controls 

note  dbol  in  Phoenix.  p3  will  be  added  to  the  OBPL  which  will  then 

note  be  passed  to  Phoenix  because  pi  in  Phoenix  controls  dbol  in 

note  Cambridge.  The  OBPL  will  then  be  disoarded  because  pi  is  active, 

rcvcm  17 

Control  message  number  17  representing  an  OBPL  has  been  received. 

Control  message  number  1 sent  from  Cambridge  to  Phoenix 

representing  an  OBPL 

rcvcm  18 

Control  message  number  18  representing  an  OBPL  has  been  received, 
note  The  next  request  creates  three  deadlocks.  When  Boston  receives 
note  the  remote  resource  request  for  dbo2,  it  creates  three  OBPL's 

note  because  there  are  three  readers  of  the  database  object.  We  will 

note  then  allow  the  three  OBPL’s  to  be  passed  among  nodes  until  all 
note  three  deadlocks  have  been  detected,  at  which  time  there  will  be 
note  no  outstanding  OBPL's  or  control  messages, 
rqdbo  exclusive  Phoenix  pi  Boston  dbo2 

Process  pi  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 

Control  message  number  19  sent  from  Phoenix  to  Boston 
representing  a remote  resource  request 

rcvcm  19 

Control  message  number  19  representing  a remote  resource  request 
has  been  received 

Resource  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Phoenix  remains  blocked 

Control  message  number  20  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

Control  message  number  21  sent  from  Boston  to  Phoenix 

representing  an  OBPL 

Control  message  number  22  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

rcvcm  21 


Control  message  number  21  representing  an  OBPL  has  been  received. 
A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Phoenix 

pi  at  node  Boston 

End  of  deadlock  list 


rcvcm  ?n 

Control  message  number  20  representing  an  OBPL 

Control  message  number  23  sent  from  Cambridge 

representing  an  OBPL 

rcvcm  22 

Control  message  number  22  representing  an  OBPL 

Control  message  number  21*  sent  from  Cambridge 

representing  an  ('CPI 


has  been  received, 
to  Boston 


has  been  received, 
to  Phoenix 
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an  OBPL 
os  ton 


rcvcm  23 

Control  message  number  23  represents 
Control  message  number  25  sent  from 
representing  an  OBPL 

rcvcm  25 

Control  message  number  25  representing  an  OBPL 
Control  message  number  2o  sent  from  Phoenix 
representing  an  OBPL 

rcvcm  26 

Control  message  number  26  representing  an  OBPL 
A deadlock  has  been  detected. 

Pj 
Pi 
P2 

End  of  deadlock  list 


has  been  received, 
to  Phoenix 


has  been  received, 
to  Cambridge 


has  been  received. 


The  following  processes  are  involved: 
at  node  Phoenix 
Cambridge 
Phoenix 
Cambridge 


at  node 
at  node 
at  node 


rcvcm  24 

Control  message  number  24  representing  an  OBPL  has  been  received. 
Control  message  number  27  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

rcvcm  27 

Control  message  number  27  representing  an  OBPL  has  been  received. 
A deadlook  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Phoenix 

p2  at  node  Cambridge 

at  node  Cambridge 

End  of  deadlook  list 


«.  ‘ 
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scenario  demo8 

note  This  is  an  example  of  a state  where  three  deadlocks  exist 
note  involving  six  processes  and  five  resources  located  in  three 

note  nodes.  Three  deadlocks  are  involved  because  dbo2  in  Boston 

note  has  three  shared  users.  Five,  rather  than  six,  resources  are 

note  involved  because  two  processes  are  waiting  for  the  same  database 

note  objact.  The  first  18  commands  create  the  state  where  all  the 

note  involved  processes  are  active  and  all  the  involved  resources 

note  have  been  allocated  to  the  proper  processes, 
rqdbo  shared  Boston  pi  Boston  dbo2 

pi  at  node  Boston  granted  shared  access  to  dbo2  at  node  Boston 
initmg  ragl  Phoenix  pi  Boston 
Message  group  mgl  has  been  initiated 
accepting  mgl  Boston  pi 

mgl  has  been  accepted  bv  pi  at  node  Boston 
rqdbo  exclusive  Phoenix  p2  Boston  dbol 

Process  p2  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Phoenix  to  Boston 
representing  a remote  resource  request 

rcvcm  1 

Coitrol  message  number  1 representing  a remote  resource  request 
has  been  received 

p2  at  node  Phoenix  is  granted  exclusive  use  of 

dbol  at  node  Boston 

Control  message  number  2 sent  from  Boston  to  Phoenix 

representing  this  allocation 

rcvcm  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  received 

p2  at  node  Phoenix  has  been  granted  exclusive  use  of 

dbol  at  node  Boston 

rqdbo  shared  Cambridge  pi  Boston  dbo2 

Process  pi  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  3 sent  from  Cambridge  to  Boston 
representing  a remote  resource  request 

rcvcm  3 

Control  message  number  3 representing  a remote  resource  request 
has  been  received 

pi  at  node  Cambridge  is  granted  shared  access  to 

dbo2  at  node  Boston 

Control  message  number  4 sent  from  Boston  to  Cambridge 

representing  this  allocation 

rcvcm  A 

Control  message  number  M representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Cambridge  has  been  granted  shared  access  to 

dbo2  at  node  Boston 

rqdbo  shared  Cambridge  p2  Boston  dbo2 

Proceaa  p2  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  5 sent  from  Cambridge  to  Poston 
representing  a remote  resource  request 
rqdbo  shared  Phoenix  pi  Cambridge  dbol 

Process  pi  at  node  Phoenix  is  blocked  while  a requr  t is  sent  to 

ii.  . . j » * • i i »•  » 

uuv  iivuw  WWUuaAliXilg  Wj  c aeon  CU  f CC  wUi'UC 

Control  message  number  6 sent  from  Phoenix  to  Cambridge 
representing  a remote  resource  request 

r c v c Tt  5 

Control  message  number  5 representing  a remote  resource  request 
has  been  received 

p?  at  node  Cambridge  is  g •'•anted  shared  access  to 

dbo?  at  node  Boston 

Control  message  number  7 sent  from  Boston 
represent i no-  this  allocation 


to  Cambridge 


’t  'f 
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rcvcm  6 

Control  message  number  6 representing  a remote  resource  request 
has  been  received 

pi  at  node  Phoenix  is  granted  shared  access  to 

dbol  at  node  Cambridge 

Control  message  number  8 sent  from  Cambridge  to  Phoenix 

representing  this  allocation 

rcvcm  7 

Control  message  number  7 representing  a remote  resource  allocation 
has  Been  received 

p2  at  node  Cambridge  has  been  granted  shared  access  to 

dbo2  at  node  Boston 

rcvcm  8 

Control  message  number  8 representing  a remote  resource  allocation 
has  Been  received 

pi  at  node  Phoenix  has  beer  granted  shared  access  to 

dbol  at  node  Cambridge 

rqdbo  exclusive  Cambridge  p3  Phoenix  dbol 

Process  p3  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  9 sent  from  Cambridge  to  Phoenix 
representing  a remote  resource  request 

rcvcm  9 

Control  message  number  9 representing  a remote  resource  request 
has  been  received 

p3  at  node  Cambridge  is  granted  exclusive  use  of 

dbol  at  node  Phoeii* 

Control  message  number  10  sent  from  Phoenix  to  Cambridge 

representing  this  allocation 

rcvcm  10 

Control  message  number  10  representing  a remote  resource  allocation 
has  been  received 

p3  at  node  Cambridge  has  been  granted  exclusive  use  of 

dbol  at  node  Phoenix 

rqdbo  exclusive  Phoenix  pi  Boston  dbo2 

Process  pi  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 1 sent  from  Phoenix  to  Boston 
representing  a remote  resource  request 
note  After  receipt  of  the  remote  resource  request,  Boston  will  send 
note  two  OBPL's  to  Cambridge  because  two  processes  in  that  node  have 

note  shared  use  of  dbo2  in  Boston.  A third  external  message  is  not 

note  needed  because  the  third  reader  of  dbo2  is  located  in  Boston 

note  and  is  active.  We  will  delay  the  receipt  of  one  of  the  OBPL's 

note  until  after  the  process  in  tne  list  that  controls  dbo2  gets 

note  blocked  waiting  for  a resource  located  in  Phoenix, 

rcvcm  1 1 

Control  message  number  1 1 representing  a remote  resource  request 
has  been  received 

Resource  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Phoenix  remains  blocked 

Control  message  number  12  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

Control  message  number  13  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

rcvcm  1? 

Control  message  number  12  representing  an  OBPL  has  been  received., 

rtrtHhA  ohonoH  ^ r*\  1 D o f-  /IKa  1 

Process  pi  at  node  ' Cambridge  is  blocked  while  a request  is  sent  to 
tne  node  containing  the  desired  resource 
Control  message  number  m sent  from  Cambridge  to  Boston 

representing  a remote  resource  request 
rcdbo  shared  hambriqjre  Phoenix  dbol 

Process  o.  at  node  Cambridge  is  blocked  while  a request  is  sent  to 
t e node  containing  the  desired  resource 
Control  me. save  number  It  sent  from  Cambridge  to  Phoenix 

representing  a remote  resource  reouect 


I 
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rcvcm  13 

Control  message  number  13  representing  an  OBPL  has  been  received. 
Control  message  number  1o  sent  from  Cambridge  to  Phoenix 
representing  an  OBPL 

note  Let  Phoenix  receive  the  OBPL  before  it  receives  the  r note  resource 

note  request  that  was  assumed  to  have  taken  place  before  tne  last 

note  process  was  added  to  the  OBPL.  The  OBPL  will  be  discarded  because 

note  Phoenix  has  no  record  that  p2  in  Cambridge  is  waiting  for  dbol 

note  in  Phoenix . 
rcvcm  16 

Control  message  number  16  representing  an  OBPL  has  been  received, 
note  Now  let  the  above  mentioned  remote  resource  request  be  received 
note  by  Phoenix.  An  OBPL  will  be  created  and  sent  to  Cambridge,  which 
note  will  then  discard  the  OBPL  because  p3  is  active, 
rcvcm  15 

Control  message  number  15  representing  a remote  resource  request 
has  been  received 

Resource  not  available,  process  remains  blooked. 

Control  message  number  17  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

rcvcm  17 

Control  message  number  17  representing  an  OBPL  has  been  received, 
note  Now  let  the  remote  resource  request  for  dbol  in  Boston  by  pi  in 
note  Cambridge  be  received  by  Boston.  An  OBPL  will  be  created  and  sent 
note  to  Phoenix,  where  p2  in  Phoenix  is  waiting  for  dbol  in  Phoenix,  so 

note  the  OBPL  will  be  passed  on  to  Cambridge  where  p3  is  active,  and 

note  the  OBPL  will  then  be  discarded, 
rcvcm  1*1 

Control  message  number  1H  representing  a remote  resource  reouest 
has  been  received 

Resource  not  available,  process  remains  blocked. 

Control  message  number  18  sent  from  Boston  to  Phoenix 

representing  an  OBPL 

rcvcm  18 

Control  message  number  13  representing  an  OBPL  has  been  received, 
rqdbo  exclusive  Phoenix  p2  Phoenix  dbol 
Resource  not  available,  process  blocked. 

Control  message  number  19  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

note  TVj  uBPL  will  be  discarded  by  Cambridge  because  p3  is  active, 
rcvcm  19 

Control  message  number  19  representing  an  OBPL  has  been  received, 
note  The  next  command  will  create  a two  process  two  resource  deadlock, 
note  An  OBPL  will  be  sent  to  Fhcsnix,  which  will  append  pi  in  Phoenix 
note  to  the  OBPL  and  send  the  OBPL  back  to  Boston  because  pi  is  waiting 

note  for  dbo2  in  Boston.  The  deadlock  will  then  be  detected,  and  two 

note  OBPL’s  will  be  sent  to  Cambridge  because  there  are  three  readers 

note  of  dbo2.  These  OBPL’s  will  then  be  passed  around  until  they 

note  return  to  Cambridge,  where  they  will  be  discarded  because  p3  in 

note  Cambridge  will  still  be  active  when  the  OBPL’s  get  examined, 

rcvmsg  mgl 

Process  pi  at  node  Boston  is  blocked  waiting  for  a 

message  in  message  group  mgl 

Control  message  number  20  sent  from  Boston  to  Phoenix 

representing  an  OBPL 

rcvcm  20 

Control  message  number  20  representing  an  OBPL  has  been  received. 
Control  message  number  21  sent  from  Phoenix  to  Boston 

representing  an  OBPL 
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revem  21 

Control  message  number  21  representing  an  OBPL  has  been  received. 
Control  message  number  22  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Boston 

pi  at  node  Phoenix 

End  of  deadlock  list 

Control  message  number  23  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

revem  22 

Control  message  number  22  representing  an  OBPL  has  been  received. 
Control  message  number  2H  sent  from  Cambridge  to  Boston 

representing  an  OBPL 

revem  2M 

Control  message  number  2M  representing  an  OBPL  has  been  received. 
Control  message  number  25  sent  from  Boston  to  Phoenix 

representing  an  OBPL 

revem  25 

Control  message  number  25  representing  an  OBPL  has  been  received. 
Control  message  number  26  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

revem  26 

Control  message  number  26  representing  an  OBPL  has  been  received, 
revem  23 

Control  message  number  23  representing  an  OBPL  has  been  received. 
Control  message  number  27  sent  from  Cambridge  to  Phoenix 

representing  an  OBPL 

revem  27 

Control  message  number  27  representing  an  OBPL  has  been  received. 
Control  message  number  28  sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

revem  28 

Control  message  number  28  representing  an  OBPL  has  besn  received, 
note  This  next  request  will  create  two  deadlocks.  An  OBPL  will  be 

note  sent  to  Phoenix,  which  will  add  pi  in  Phoenix  to  the  list  and 

note  send  it  to  Boston.  Boston  wili  then  send  out  three  OBPL'S, 
note  one  for  each  reader  of  dbo2  in  Boston.  These  OBPL’s  will  be 

note  passed  among  the  various  nodes  until  there  are  no  more  OBPL's 

note  and  control  messages  outstanding.  Note  that  the  two  process  two 

note  resource  deadlock  will  be  detected  for  a second  time  because  of 

note  the  fact  that  pi  in  Boston  still  has  shared  access  to  dbo2  in 

note  Boston  and  the  deadlock  has  not  been  broken  by  aborting  any 

note  processes. 

rqdbo  exclusive  Cambridge  p3  Cambridge  dbol 

Resource  is  not  currently  available  for  exclusive  use,  process  p3 
at  node  Cambridge  is  blocked. 

Control  message  number  29  sent  from  Cambridge  to  Phoenix 

representing  an  OBPL 

revem  29 

Control  message  number  29  represent ing  an  OBPL  has  been  received. 
Control  message  number  30  sent  from  Phoenix  to  Boston 

representing  an  OBPL 

revem  30 

Control  message  number  30  representing  an  OBPL  has  been  received. 
Control  message  number  31  sent  from  Boston  to  Cambridge 

representing  ar^OBPL 

curitrux  ruiissagc  nuiiiuci  jc  oci.w  u vir  buc \s\si ' tc  Phccri« 

representing  an  OBPL 

Control  message  number  33  sent  from  Boston  to  Cambridge 

representing  an  OBPL 

rrvcm  3? 

Control  message  number  32  representing  ar.  OBPL  has  been  received. 

A deadlock  has  been  detected.  The  following  processes  are  involved:. 

pi  at  noae  Phoenix 

pi  at  node  Boston 

Kr.d  of  deadlock  list 
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rcvcm  31 

Control  message  number 
Control  message  number 

representing  an  OBPL 

rcvcm 

Control  message  number 
Control  message  number 

representing  an  OBPL 

rcvcm  35 

Control  message  number 


J4 

)5 


representing  an  OBPL 
sent  from  Cambridge 


representing 
sent  from  Bi 


an  OBPL 
oston 


has  been  received, 
to  Boston 


has  been  received, 
to  Phoenix 


A deadlock  has  been  detected. 

P3 
Pi 
pi 

p2 

End  of  deadlock  list 


35  representing  an  OBPL  has  been  received. 


The  following  processes  are  involved: 
at  node  Cambridge 

at  node  Phoenix 

at  node  Cambridge 

at  node  Phoenix 


rcvcm  33 

Control  message  number  33  representing  an  OBPL  has  been  received. 
Control  message  number  36  sent  from  Cambridge  to  Phoenix 
representing  an  OBPL 

rcvcm  36 

Control  message  number  36  representing  an  OBPL  has  been  received. 
A deadlock  has  been  detected.  The  following  processes  are  involved: 

p3  at  node  Cambridge 

pi  at  r.ode  Phoenix 

p2  at  node  Cambridge 

End  of  deadlock  li-st 
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Phoenix 


resource  request 


scenario  demo9 

note  This  is  an  example  of  a case  where  a process  releases  a remote 
note  database  object  and  sends  a remote  resource  control  message  at 

note  the  same  time  that  an  OBPL  is  sent  to  this  node  stating  that  some 

note  other  process  is  waiting  for  the  resource  mentioned  above,  which 
note  is  controlled  by  the  first  process  mentioned  above.  Before  the 

note  OBPL  arrives,  the  first  process  gets  blocked  waiting  for  a resource 

note  that  is  controlled  by  the  process  that  was  placed  in  the  OBPL. 
note  No  deadlock  is  detected  because  the  resouroe  in  question  is  no 

note  longer  controlled  by  the  last  process  to  be  added  to  the  OBPL. 

rqdbo  shared  Boston  pi  Phoenix  dbol 

Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resouroe 
Control  message  number  1 sent  from  Boston  to 
representing  a remote  resource  request 

rcvcm  1 

Control  message  number  1 representing  a remote 
has  been  received 

pi  at  node  Boston  is  granted  shared  access  to 

dbol  at  node  Phoenix 

Control  message  number  2 sent  from  Phoenix  tc  Boston 

representing  this  allocation 

rcvcm  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Boston  has  been  granted  shared  access  to 

dbol  at  node  Phoenix 

rqdbo  exclusive  Phoenix  nl  Boston  dbol 

Process  pi  at  node  Phoenix  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  3 sent  from  Phoenix  to 
representing  a remote  resource  request 

rcvcm  3 

Control  message  number  3 representing  a remote 

has  been  received 

pi  at  node  Phoenix  is  granted  exclusive  use  of 

dbol  at  node  Boston 

Control  message  number  4 sent  from  Boston  to  Phoenix 

representing  this  allocation 

rcvcm  4 

Control  message  number  4 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Phoenix  has  been  granted  exclusive  use  of 

dbol  at  node  Boston 

rqdbo  shared  Boston  pi  Boston  dbol 

Resource  not  available,  process  blocked. 

Control  message  number  5 sent  from  Boston  to  Phoenix 

representing  an  OBPL 

note  Let  dbol  in  Boston  be  released  by  pi  in  Phoenix,  and  let  pi  in 

note  Phoenix  then  get  blocked  waiting  for  dbol  in  Phoenix  before  the 

note  OBPL  from  Boston  is  received  by  Phoenix, 
rldbo  Phoenix  pi  Bos  con  dbol 

Control  message  number  6 sent  from  Phoenix  to 
representing  a remote  resource  release 

rcvcm  6 

Control  message  number  6 representing  a remote 
has  been  received 

uuui  al  uuuc  uosLuii  iids  use n released  uy 

pi  at  node  Pnoenix 

Process  pi  at  node  Boston 

dbol  at  node  Boston 

rqdbo  exclusive  Phoenix  pi  Phoenix  dbol 

Resource  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Phoenix  is  blocked. 

Control  message  number  7 sent  from  Phoenix 
representing  an  OBPL 


Boston 


resource  request 


Boston 


resource  release 


is  granted  shared  access  to 


to  Boston 
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rcvcm  7 

Control  message  number  7 representing  an  OBPL  has  been  received, 
note  No  deadlock  will  be  detected  because  Phoenix  observes  that  pi  in 

note  Phoenix  no  longer  has  access  to  dbol  in  Boston,  and  discards 

note  the  OBPL. 
rcvcm  5 

Control  message  number  5 representing  an  OBPL  has  been  received. 


Boston  Phoenix 


State  where  control  message  5 has  just  been  sent  from  Boston  to  Phoenix. 
Control  message  5 represents  an  OBPL.  Receipt  of  the  OBPL  is  delayed  until 
after  the  state  drawn  below  is  reached. 


Boston  Phoenix 


Final  State  Diagram 
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scenario  demo 10 

note  This  is  an  example  where  «n  OBPL  Is  sent  from  Boston  to  Phoenix 

note  stating  that  a process  in  Boston  Is  waiting  for  a message  from  a 

note  process  in  Phoenix.  Before  the  OBPL  arrives  in  Phoenix,  the 

note  desired  message  is  sent,  and  the  process  in  Phoenix  gets  blocked 

note  waiting  for  a resource  that  is  controlled  by  the  process  that  was 

note  placed  in  the  OBPL  that  was  sent  from  Boston  to  Phoenix.  No 

note  deadlock  is  detected  because  Phoenix  notices  that  the  message 

note  that  was  desired  by  the  process  in  Boston  has  already  been  sent, 

note  The  first  six  commands  create  the  state  where  the  OBPL 

note  mentioned  above  has  just  been  sent, 

initmg  mgl  Phoenix  pi  Boston 
Message  group  mgl  has  been  initiated 
accepting  mgl  Boston  pi 

mgl  has  been  accepted  by  pi  at  node  Boston 
rqdbo  exclusive  Boston  pi  Phoenix  dbol 
Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 
Control  message  number  1 sent  from  Boston  to  Phoenix 
representing  a remote  resource  request 

revcm  1 

Control  message  number  1 representing  a remote  resource  request 
has  Been  received 

pi  at  node  Boston  is  granted  exclusive  use  of 

dbol  at  node  Phoenix 

Control  message  number  2 sent  from  Phoenix  to  Boston 

representing  this  allocation 

revcm  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  received 

pi  at  node  Boston  has  been  granted  exclusive  use  of 

dbol  at  node  Phoenix 

rcvmsg  mgl 

Process  pi  at  node  Boston  is  blocked  waiting  for  a 

message  in  message  group  mgl 

Control  message  number  3 sent  from  Boston  to  Phoenix 

representing  an  OBPL 

note  We  will  now  temporarily  delay  receipt  of  the  OBPL  by  Phoenix, 
note  Send  the  message  that  the  process  in  Boston  desires, 
sendmsg  mgl 

Control  message  number  M sent  from  Phoenix  to  Boston 

representing  a message  in  a message  group 
note  Let  the  process  in  Boston  receive  the  message, 
revcm  4 

Control  message_number  4 representing  a message  in  a message  group 
has  been  received 

Process  pi  at  node  Boston  has  been  awakened  upon 

receipt  of  a message  in  message  group  mgl 
note  Block  pi  in  Phoenix  and  then  let  Boston  discard  the  OBPL  that 
note  will  be  created  as  a result  of  this  wait, 
rqdbo  shared  Phoenix  pi  Phoenix  dbol 

Resource  not  available,  process  blocked. 

Control  message  number  5 sent  from  Phoenix  to  Boston 

representing  an  OBPL 

revcm  5 

Control  message  number  5 representing  an  OBPL  has  been  received, 
note  Now  let  Phoenix  receive  the  OBPL  that  was  Dreviouslv  sent  hv 
note  boston, 
revcm  3 

Control  message  number  3 representing  an  OBPL  has  been  received. 
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scenario  demolO 


State  where  oontrol  message  3 representing  an  OBPL  has  Just  been  sent 
from  Boston  to  Phoenix.  Receipt  of  the  OBPL  is  delayed  until  after  the  state 
drawn  below  is  reached. 


TC 
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scenario  demo 11 


scenario  demon 

note  This  is  an  example  of  a deadlock  involving  one  process  and  one 
note  operator  at  the  same  node.  Two  operator  connections  are  involved, 
dolop  Boston  opl 

opl  has  been  declared  as  an  operator  at  node  Boston 
copcon  coni  Boston  opl  pi 
operator  connection  coni  has  been  established 
copcon  con2  Boston  op1  pi 
operator  connection  con2  has  been  established 
note  Let  pi  in  Boston  request  a message  from  operator  opl  in  Boston 


rcvopmsg  coni 
Process  pi 

message 


at  node  Boston  is  blocked  waiting  for  a 

over  operator  connection  coni 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator  opl 
at  node  Boston  The  involved  operator  connection  is  coni 

note  Create  a deadlock  by  reporting  thst  opl  is  waiting  for  a message 
note  over  operator  connection  eon2. 
opstat  Boston  opl  waiting  eon2 

We  will  now  check  for  aeadlook  involving  the  given  operator 
and  operator  connection 

A deadlock  has  been  detected.  The  following  processes  are  involved: 

pi  at  node  Boston 

opl  at  node  Boston 

End  of  deadlock  list 
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scenario  demo12 


scenario  deno12 


This  is  an  example  of  a deadlock  across  three  nodes  which  involves 
several  operator  oonneotions.  It  demonstrates  that  deadlock 
involving  operators  will  be  detected  as  long  as  the  operator 
properly  states  what  he  is  waiting  for.  The  first  15  commands 
set  up  the  state  where  all  operators  have  been  declared,  all 
operator  connections  have  been  created,  the  message  group  has 
been  initiated  and  accepted,  and  the  involved  database  objects 
have  been  assigned  to  tne  proper  processes. 

Boston  opl 

has  been  declared  as  an  operator  at  node  Boston 


dcloo  Phoenix  opl 

opl  has  been  declared  as  an  operator  at  node 
dolop  Boston  op2 

op2  has  been  deolared  as  an  operator  at  node  Boston 
copoon  coni  Boston  opl  pi 
Operator  connection  coni  has  been  established 


Phoenix 


copcon  con2  Boston  opl  p2 
Operator  connection  con2 
copoon  con3  Boston  op2  p2 
Operator  connection  oon3 
copcon  con1*  Boston  op2  p3 
Operator  connection  con1* 


has  been  established 
has  been  established 


perator  connection  con1*  has  been  established 


copcon  con5  Phoenix  opl  p2 
Operator  connection  con! 
copcon  eons  Phoenix  opl  pi 


has  been  established 


V VWVV»»  WVHV  * UWV«44>A  V|^  I I 

Operator  connection  con6  has  been  established 
initmg  mgl  Cambridge  pi  Phoenix 

Message  group  mgl  has  been  initiated 
acoeptmg  mgl  Phoenix  pi 

mgl  has  been  aocepted  by  pi  at  node  Phoenix 
rqdbo  exclusive  Boston  p3  Cambridge  dbol 


Process 


p3  at  node  Boston  is  blooked  while  a request  is  sent  to 
tne  node  containing  the  desired  resouroe 


Control  message  number  1 sent  from  Boston  to  Cambridge 
representing  a remote  resouroe  request 

rcvem  1 

Control  message  number  1 representing  a remote  resource  request 
has  been  reoeived 

p3  at  node  Boston  is  granted  exclusive  use  of 

dbol  at  node  Cambridge 

Control  message  number  2 sent  from  Cambridge  to  Boston 
representing  this  allocation 

rcvcm  2 

Control  message  number  2 representing  a remote  resource  allocation 
has  been  reoeived 

p3  at  node  Boston  has  been  granted  exclusive  use  of 

dbol  at  node  Cambridge 

rqdbo  shared  Phoenix  p2  Phoenix  dbol 

p2  at  node  Phoenix  granted  shared  aocess  to  dbol  at  node  Phoenix 
note  Let  pi  in  Boston  wait  for  exclusive  use  of  dbol  in  Phoenix.  No 

note  deadlock  will  be  detected  because  p2  in  Phoenix,  which  controls 

note  dbol  in  Phoenix,  is  active, 
rqdbo  exclusive  Boston  pi  Phoenix  dbol 

Process  pi  at  node  Boston  is  blocked  while  a request  is  sent  to 
the  node  containing  the  desired  resource 

Control  message  number  3 sent  from  Boston  to  Phoenix 
representing  a remote  resource  request 

rcvcm  3 

Control  message  number  3 representing  a remote  resource  request 
has  been  received 

Resource  is  not  currently  available  for  exclusive  use,  process  pi 
at  node  Boston  remains  blocked 
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scenario  demo 12 


note  Let  p2  in  Phoenix  now  wait  for  a message  from  opl  in  Phoenix, 
note  We  then  state  that  cpI  in  Phoenix  is  active,  so  no  OBPL's  get 
note  expanded  further, 
rcvopmsg  con5 

Process  p2  at  node  Phoenix  is  blocked  waiting  for  a 

message  over  operator  connection  con5 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator  opl 

at  node  Phoenix  The  involved  operator  connection  is  con5 

opstat  Phoenix  opl  active 

All  OBPL's  waiting  for  the  given  state  information  have  been  discarded 
note  Let  pi  in  Phoenix  wait  for  a message  from  pi  in  Cambridge.  No 
note  deadlock  exists  because  pi  in  Cambridge  is  active, 
rcvmsg  mgl 

Process  pi  at  node  Phoenix  is  blocked  waiting  for  a 

message  in  message  group  mgl 

Control  message  number  4 sent  from  Phoenix  to  Cambridge 

representing  an  OBPL 

rcvcm  4 

Control  message  number  4 representing  an  OBPL  has  been  received, 
note  Let  p3  in  Boston  wait  for  a message  from  op2  in  Boston.  The 

note  OBPL  created  when  p3  gets  blocked  will  be  discarded  when  we 

note  state  that  op2  is  active, 
rcvopmsg  con4 

Process  p3  at  node  Boston  is  blocked  waiting  for  a 

message  over  operator  connection  con4 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator  op2 
at  node  Boston  The  involved  operator  connection  is  con4 

opstat  Boston  op2  active 

All  OBPL's  waiting  for  the  given  state  information  have  been  discarded 
note  Simultaneously  block  pi  in  Cambridge  and  p2  in  Boston.  Then 
note  let  Boston  receive  the  OBPL  from  Cambridge  that  was  created 

note  when  pi  in  Cambridge  was  blocked.  Before  we  report  the  status 

note  of  opl  in  Boston,  state  that  op2  in  Boston  is  waiting  for  a 
note  message  from  p2  in  Boston,  thereby  queuing  a second  OBPL  for 
note  information  on  the  status  of  opl  In  Boston, 
rqdbo  shared  Cambridge  pi  Cambridge  dbol 

Resource  not  available,  process  blocked. 

Control  message  number  5 sent  from  Cambridge  to  Boston 
representing  an  OBPL 
rcvopmsg  con2 

Process  p2  at  node  Boston  is  blocked  waiting  for  a 


message  over  operator  connection  con2 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator 
at  node  Boston  The  involved  operator  connection  is 

rcvcm  5 

Control  message  number  5 representing  an  OBPL  has  been  received. 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator 
at  node  Boston  The  involved  operator  connection  is 

opstat  Boston  op2  waiting  conB 

We  will  now  check  for  deadlock  involving  the  given  operator 
and  operator  connection 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator 
at  node  Boston  The  involved  operator  connection  is 

opstat  Boston  opl  waiting  coni 

We  will  now  check  for  deadlock  involving  the  given  operator 
and  operator  connection 

Control  message  number  6 sent  from  Boston  to  Phoenix 


opl 

con2 


op2 

con4 


opl 

con2 


representing  an  OBPL 

rnnf  1 mooocwro  mimhoy  *7  f v*/sm 


Da  © 


f A v 


representing  an  OBPL 

note  There  were  two  OBPL's  waiting  for  state  information  from  opl  in 
note  Boston,  therefore  two  OBPL’s  are  expanded  and  sent  to  Phoenix, 
note  Let  Phoenix  receive  and  expand  both  OBPL's,  and  state  that  opl 

note  in  Phoenix  is  waiting  for  a message  from  pi  in  Phoenix,  thereby 

note  closine  the  deadlock  loop.  The  deadlock  will  be  detected  twice 

note  because  we  had  two  OBPL's  being  passed  around  due  to  the  fact 

note  that  we  blocked  two  processes  simultaneously. 
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rcvcm  6 

Control  message  number  6 representing  an  OBPL  has  been  received. 

An  OBPL  has  been  queued  waiting  for  a status  report  from  operator 
at  node  Phoenix  The  involved  operator  connection  is 

rcvcm  7 

Control  message  number  7 representing  an  OBPL  has  been  received. 

An  OBPL  has  been  queued  waiting  for  a status  reoort  from  operator 
at  node  Phoenix  The  involved  operator  connection  is 

opstat  Phoenix  opl  waiting  con6 

We  will  now  check  for  deadlock  involving  the  given  operator 
and  operator  connection 

Control  message  number  8 sent  from  Phoenix 


opl 

con5 


opl 

con5 


representing  an  OBPL 
Control  message  number  9 sene  from  Phoenix 
representing  an  OBPL 


rcvcm  8 
Control 
Control 

revoffi  9 


message  number 
message  number 
renresenting  an 


8 representing  an  CBFL 
ir>  sent  from  Cambridge 
OBPL 


to  Cambridge 
to  Cambridge 


has  been  received, 
to  Boston 


Control  message  number  9 representing  an  OBPL  has  been  received, 
deadlock  has  been  detected.  The  following  pre 


rcvcm  10 


End  of 


Pi 
p30 

IV 

p2, 

opl 

pi 

deadlock 


list 


at 

at 

at 

at 

at 

at 

at 

at 

at 


node 

node 

node 

node 

node 

node 

node 

node 

node 


processes 
Cambridge 
Boston 
Boston 
Boston 
Boston 
Boston 
Phoenix 
Phoenix 
Phoenix 


are  involved: 


Control  message  number  10  representing  an  OBPL  has  been  received, 
An  OBPL  has  been  queued  waiting  for  a status  report  from  operator 

The  involved  operator  connection  is 


at  node  Boston 
opstat  Boston  op2  waiting  con3 

We  will  now  check  for  deadlock  involving  the  given 
and  operator  connection 


op2 

conH 


operator 


A deadlock  has 


been  detected, 
P2 
opl 

pi 

p2 

opl 

Pi 
Pi 
P3_ 


The  following  processes  are  involved: 


ODt 

End  of  deadlock  list 


at  node 
at  node 
at  node 
at  node 
at  node 
at  node 
at  node 
at  node 
at  node 


Boston 
Boston 
Boston 
Phoenix 
Phoenix 
Phoenix 
Cambridge 
Boston 
Boston 
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